Strategic Focus

Is Lack of Strategic Focus Killing Your Business?

Instead of focusing on improving the processes that directly affect core business competency, many businesses invest enormous amounts of money, too much time, and human effort on software engineering and reengineering.

Valuable capital assets are spent on maintaining and upgrading systems that hinder business continuity and lack future adaptability. Executive strategic direction and employee activities remain disconnected. Consequently, related business functions fail to provide useable information that can be applied to achieve organizational goals and objectives.

Strategic Focus Aided By Integration

Smart business management teams utilize integration as a portal to their business processes; thereby, creating real-time snapshots of the business.

Booker Showers

A Bad Error Handling Strategy Can Ruin the Best Application

This article addresses the importance of establishing an error handling framework, specially exceptions generated by APIs.

API error handling should be part of developer planning and support. During the planning definition phase, the following questions require answers.

  • Why is the error needed?
  • What action is required because of an error?
  • Who is the audience for the error?
  • Where should the error display?
  • How is the error generated?

Review an example of any significant system or application extended outage and you’ll surmise the outage was a direct result of one or more of the following.

  • Not enough documentation
  • No information about the cause
  • Poor error handling
  • Most importantly―a poor error handling framework

Error handling operates at a higher level than architectural application exceptions. An error handling framework acts as a “sanity check” for API developers. A thorough error handling framework defines proper policy and service exceptions that system administrators or developers can act upon to correct.

When I speak of frameworks, I’m speaking about defined sets of basic standards that can be reused. The practice of creating a framework not only applies to code, but to error handling. You may not think of error handling as having a separate framework, but establishing an error handling framework that has laser focus, dedicated attention can reap tremendous rewards in the following ways.

  • Maintaining a stable system
  • Allowing developers to quickly troubleshoot problems
  • Aid extending applications
  • Quickly ramp-up new developers

Applications developed upon code foundations, or other applications, depend on diagnostics to determine and promptly resolve problems.

Developers should create application-specific exceptions. Exceptions defined in systems may be specific, but can occur in different places. However, it is helpful to define detailed user-friendly exceptions.

Nested exceptions include the original exception and detailed messages specific to the context of an application.

In developing an exception framework consider generating exceptions only if an application can recover (or partially recover) from the error. If unable to recover from an error, issue a custom exception that encapsulates the original exception (if applicable) and includes a meaningful message.

Only generate custom exceptions for more meaningful error handling. When issuing an exception, provide a meaningful and descriptive message. If possible, include specific values.

A good error handling framework divides errors for easily recognized and appropriate action:

  • Policy Errors – based on business rules, which are set to baseline business requirements.
  • Service Errors – generated at a network level when a network cannot process the incoming request.
  • System Errors – returned from a core system from the underlying network.
  • Business Errors – an operation failed because business logic cannot produce a successful response because of passed data.

The Art of Under Promising and Over Delivering

According to the McKinsey/Oxford study half of IT projects with budgets of over $15 million dollars run 45% over budget, are 7% behind schedule and deliver 56% less functionality than predicted (Bloch, Blumberg, and Laartz, 2012).

Providing value as a consultant to a client without compromising the bottom line of either the consulting company or the client is an art. Consultants deserve compensation commensurate with their level of intellectual capital gained through knowledge and expertise. Clients deserve to receive services that solve the problems consultants are engaged to disentangle. To build a strong foundation that creates a successful client-consultant relationship requires honest communication on both sides during the elicitation and analysis of requirements phase.

During the relationship-building negotiation phase, a client wants the lowest price for the least amount of hours to complete a project. The consulting company must understand what the client wants to achieve and determine if client expectations can be met within the budget and hours the client has in mind. Consultants must deliver on time, add value, and make a profit. Overcoming the challenge of immediate cost savings on the client side and the true costs for a project on the consultant company’s side is a delicate balance. A balance that if lopsided will negatively affect the success of project goals. If a consulting company accepts terms they know are unrealistic, client expectations are not met. Under promising and over delivering takes practice, wisdom, and time to perfect.

Experience is one of the keys to achieving this balance. Wise consultants understand the power of managing a client’s expectations. Professional consultants do not over promise, or suggest a client lower expectations and submit a plan that really does not provide the ideal solution. Honest communication with a client is based on showing how the consulting company’s plan will drive value, even if the price point is above the client’s initial budget consideration. Deliverables that make the client happy set a precedence for solidifying additional work, and creating a long-term, win-win relationship.

Frequently, consultants have a solution in mind before approaching or establishing a relationship. Projects are less likely to succeed when preconceptions get in the way rather than providing advice based on client needs. The preconceived notion approach is the default position for the super-salesperson who is less worried about building a long-term relationship with a client, and more concerned with short-term, new business transactions accomplished by recommending solutions du jour.

Ultimately, the key ingredient to keeping clients happy is active listening. Effective listening is a skill. Some people are skilled listeners. Many are not. Effective listening allows a consultant to accurately, communicate client project expectations and anticipate client needs.

Remember, don’t take on more than you are prepared to be held accountable for. Provide evidence-based estimates with confidence. Resist the temptation to guesstimate about what your client truly needs, and prevent your projects from becoming IT failure statistics.

Bloch, Blumberg, and Laartz. (2012). Delivering large-scale IT projects on time, on budget, and on value. McKinsey&Company. Retrieved from

Moving From Pieces to Harmonic Processes

Software Integration – Moving From Pieces to Harmonic Processes

Achieving business objectives requires a seamless flow of information between all business functions.

Multiple business departments need integrated information flow:

  • To retain customers
  • Capture customer information
  • Follow up with clients
  • Receive a customized request for a product or service
  • Product design
  • Manage processes
  • Deliver finished goods
  • Collect payments

Further, to execute complex processes efficiently quick data exchange between applications through efficient software integration is necessary.

Achieving an ideal solution requires one of two actions:

  1. Integrating and customizing existing applications, which can be time consuming and result in a hodgepodge of programs strung together with complex coding and programming processes.
  2. Adopting flexible applications designed, developed, and supported to work together.


Why You Should Care About XML Schemas

Why SchemasXML schemas should not be confused with XML. Schemas allow you to set rules that apply to XML documents. Rules are good; especially, for XML documents. Schemas define the structure of an XML document. Rules also assist novice XML authors from making mistakes when adding content to an XML document because rules govern what goes in an XML document, and what should be excluded.

Developers often create schemas with optional XML elements. Which begs the question: Are you authoring the schema to determine its structure, or are you authoring a schema to define the rules for content added to an XML document?

If you are creating a schema to define an XML document structure, don’t.

Often XML schemas are reversed engineered from XML documents⎯NOT the correct way to author schemas. One should design a schema.  In designing, we must think about what elements are needed in an XML document. Considerations include how to structure the document, what rules to place on the data, and if only certain information should be allowed in the XML document. The proper way to approach schema design does not include reverse engineering an XML concept document to reduce typing.

Sorry, creating a schema is a dirty job. However, the rewards are bountiful when designed appropriately.  Appropriately designed schemas produce consistent XML documents, consistent content, reusable content, and structure content.

Versioned Governance

Versioned Governance

Versioned GovernanceREST resources and components are meant to be used in more than one application. Organizations should plan for the incremental enhancement of resources over a long deployment lifetime. Essentially, organizations planning to build a robust, stable, and extensible REST resource need to treat resources as “products.”

What does treating a resources as a “product” mean to our IT organization?

  1. Each produced resource must have a regular and well-defined release cycle. The release cycle should occur often enough to meet consumer needs on a timely basis. However, not so often as to churn existing consumers. Typically, an appropriate release cycle for most organizations is between three and six months, which allows organizations to meet new resource needs without unduly disrupting existing applications. When multiple versions of a resource are released, consider defining the life-cycle states for your resources:

Under Development: Available for requirements gathering and application development team planning purposes

–  Production: Mainline version for use in new development

–  Retired: Still in use by existing applications but not allowed for use by new apps

–  Obsolete: All applications should be migrated off this version; version metadata is maintained for traceability/audit purposes only

2. Resources must preserve backward compatibility when possible. Deprecation techniques (where obsolete operations are identified, and notice given to consumers operations will be removed from resource interfaces in future releases) gives existing consumers time to migrate to newer resource releases. Additionally, resource providers should offer n-1 version support at a minimum. All resources provided in a prior version (except ones marked as deprecated) should be preserved intact in the current version. Moreover, consider offering a “grace period” for both resource versions during deployment to allow consumers to make necessary changes while integrating to the new resource version. Dynamic run-time binding techniques via Web resources management infrastructure also simplify the migration process from an old-to-new resource version.

3. The enterprise architecture and resource review teams need to establish mechanisms for gathering requirements from current and potential “customers.” Consider establishing a “product manager” role within the organization, one that manages the aggregate set of business requirements for the resource, and works to prioritize requirements with its current, and potential customers.

Again, a well-designed discovery mechanism helps an organization manage the lifetime of resource versions with automated notifications, and embedded discussion forums for requirements gathering. Further, analysis through filter-based search capabilities, which expose resources to potential consumers based on a resources state, also result from a well-designed discovery mechanism.

Adapt Don't Implement

Adapt Don’t Implement


ModelViewController style application programming.


Adapt Don't ImplementYou have some object, nicely modeled to represent your solution domain. Next, you have to visualize the object (the model) with more than one widget (view/controller). Each widget has its own set of Events, Listeners, and requires the model to implement a widget-specific model interface.

Now, you can start to implement one model interface after the other, which creates two problems:

1) The class becomes cluttered with interfaces

2) You cannot use default, basic or abstract implementations. All listener handling needs to be coded from scratch.


Don’t implement all the interfaces at your data model. Instead, design the interface of your data model in a generic, domain-specific way.

Provide the data model with a notification/listener interface, allowing the data model to receive notifications specific to the model.

Use the AdapterPattern to provide widget-specific interfaces. Adapt the model’s get/set methods; including, the model’s listener/notification methods to the ones needed by specific widgets.

The adapter is derived from the default, basic or abstract model implementations that exist for the widgets under discussion, providing a head start for listener and event handling.
The adapters take an instance of the model as argument for their constructors.

What Happened to Good Ol' Competition - Is Innovation Dead?

What Happened to Good Ol’ Competition – Is Innovation Dead?


Back in the day, not too long ago, there were many companies competing in a specific marketplace for customers, not consumers. The customer was always right. Companies valued customers. Competition made services and products attractive to customers, and they flocked to the companies that not only provided the best products, but also the best customer service.

Today, customer service is a distant memory in many cases. A customer is no longer treated as valuable, but instead has transitioned into a consumer. Consumers have been deemed a company right. In multiple ways, innovation has taken a back seat. There is a pervasive herd mentality. Instead of different thinking and innovation, too many companies follow the crowd and conform. If companies don’t conform for whatever reason, litigation becomes a significant obstacle for nonconformists.

Companies become more powerful through acquisition by creating industry specific oligopolies, or a monopoly as opposed to the good old days of competition (Circa the advent of the Internet). Increasingly, today’s competition is wrapped up in patent trolls, and licensing litigation. Competition seems to exist only in sports and politics (if we believe what we see is true). The business world has seceded from the world of competition.

This article is not intended to point a finger at any one company, but to highlight a development in the business world that crosses industries, and detracts from innovation and unadulterated competition.

We need to consider how best our global future can be served by restricting new ideas and experimentation from those of us who have much to contribute. Should monopolistic behavior and litigation serve as the backbone of the business world in the 21st century, I think not.

Booker Showers

REST Will Soon Fade into Oblivion

REST Will Soon Fade into Oblivion

Like other promising technologies I can confidently state that REST will soon head to the technological graveyard. Why? The use of REST seems to be based on opinions instead of rules. I don’t understand how REST turned into such a mishmash of divergent technologies when there is actually a well documented thesis written on the subject. We are in an era where loose interpretation of REST causes confusion for companies trying to implement the architectural style.

The REST technology leaders are dictating the market direction of REST on faulty material or hearsay. If only I had a nickel for every time I have been told that my arguments on proper REST architecture are academic, I would be rich. When people mention the term REST API, I automatically know they have no clue about REST. The sad part is that this term is repeated on site after site, blog after blog. Representational State Transfer Application Programing Interface? Seriously? This ill-conceived grouping of acronyms I predict will bury REST.

An architectural style originally developed for exploiting the Internet for data access turned into a mechanism that creates functional interfaces is a sure sign that REST is headed towards extinction, which usually happens when there is a complete misunderstanding of an architecture’s intent. Unfortunately, REST is now used as another buzz acronym and to pad resumes.

However, REST is simply an architectural style developed to transfer data in a usable fashion utilizing HTTP. The evidence of REST implementation lies in the verbs used, and its usage similarity to the database domain. Create, Retrieve, Update, and Delete in the database domain. POST, GET, PUT, and DELETE in the HTTP domain.

How much more evidence is needed to convey that REST is for data, and not for interfaces and function calls? Nevertheless, market leaders are force fitting REST as the new SOAP. I surmise this is because most of the architects are former SOAP architects. The SOAP architects are using analogies they are most familiar with – SOAP.

SOAP is not REST. SOAP is functional. REST is data. Regrettably, we will never see implementations that reflect the academic argument because the market drivers have already dictated that REST is the new SOAP. Consequently, REST extinction in 5 years or fewer is indeed possible; unless the IT industry reevaluates its understanding of Roy Fielding’s academic thesis as intended in real-world applications.

Booker Showers

REST Governance Key Signature

The REST Governance Key Signature


Much of the hype around service governance is focused on operational governance. Defining, tracking, and managing factors like service-level agreements (e.g., average response time, peak response time, average throughput, peak throughput) and authorization policies (e.g., users from organization A are allowed to invoke this service while users from organization B are not) are very important.  Once service components are up and running within an organization’s IT infrastructure governance is necessary.

Operational governance and management are necessary but insufficient for successful service deployment. To effectively define and implement a REST service, and not simply implement a series of point-to-point REST services masquerading as REST, which create another layer of technology spaghetti, REST services must extend governance back to development and architectural REST perspectives. Find a way to seamlessly bind REST perspectives to enable effective information flow in multiple directions⎯from architecture to development to operations.

Taliferro thoroughly investigated each governance perspective.

Architectural Governance

Architectural governance at the enterprise architecture (EA) level involves three key elements:

  1. core decisions about business or technological functionality within the enterprise
  2. documenting decisions so that downstream consumers (the teams responsible for developing and deploying services and    applications) can quickly understand and make effective use of those decisions
  3. reviewing project-specific application of decisions

In order for an EA team to execute tasks, the team must have an effective way to disseminate produced knowledge assets. In addition, the team must track and understand which knowledge assets are applied to specific projects. Further, an EA Team needs to document the review of project-specific decisions.

Design-Time Governance

In many ways, Software Development Life Cycle (SDLC) governance within a REST initiative is a reflection of decisions made at the enterprise architecture (EA) level. Decisions about the scope and granularity of implemented business services and technical approach used in implementing the services must be applied to specific service production or consumption (i.e., application development) projects.

However, SDLC governance extends beyond appropriate application of EA guidance to the analysis, design, implementation, and testing of the resulting services and/or applications required by the IT project. Regarding service production, SDLC governance involves the progressive “hardening” of a service. Services progress through requirements definition, design, implementation/unit test, and integration/system test phases to eventual deployment in the operational environment, oversight is needed.

When applied to service consumption, governance may involve both internal project-specific reviews (e.g., appropriate services selected, requirements for new services identified). External reviews from the perspective of service providers allow for such questions as:

Does the use of this service within this application conform to enterprise-specific or government-mandated privacy rules?

Does the service implementation contain open source components?  If so, do the components compromise enterprise-specific intellectual property?

Operational Governance

Operational governance/management within REST involves applying appropriate business and technical policies (e.g., groups and users allowed to invoke a particular service, minimum throughput and response time expectations required of a service) to deployed services. Business policies are often implemented within REST by a Service Bus or some fabric integrated with the enterprise’s authentication and authorization infrastructure, while technical policies are typically monitored by a services management platform. The cumulative set of governed technical policies is often referred to as a service-level agreement (SLA).

Examples of SLA-level technical governance elements within REST:

  • Average throughput
  • Peak throughput
  • Type and description of committed SLA
  • Availability
  • Consuming service clients
  • Hardware and software configuration
  • Fault history
  • Alert thresholds

Political Aspects of REST Governance

How do we map  governance disciplines into an organization’s structure and roles? The nature of REST governance creates a new discipline with implications for existing corporate and IT institutions. The implications affect new organizational structures and processes and the politics associated with those structures and processes.

To make governance a valuable and necessary function that supports REST migration one needs to understand

  • corporate service policies
  • what governance means
  • how governance helps achieve successful implementation
  • the impact on current IT governance processes.

Some processes include budgeting and project approval, portfolio management activities, and ongoing oversight of projects to assure budgetary compliance. Applying governance to REST activities is critical because changes to normal IT governance processes for budgeting and portfolio management may be necessary.

Think about the budgeting process of an organization. The budgeting process has tremendous impact on organizational behavior in general, and IT departments in particular. Without budgetary project control to influence REST adoption and reusable services as fundamental design concepts, projects are only driven by requirements of a specific business unit, or project. The same logic applies to portfolio management.  Governance, budgeting, and portfolio management are methods used to influence business unit behavior, and IT departments to aggressively support REST and reuse. Enterprise architecture processes undergo changes as a result of an organization’s REST initiative. Often the architecture process and organization have to be restructured to accommodate REST requirements because the skills, roles, and functions of an EA team are not appropriate for a REST initiative.

Examine the process of architecture as tiers of activities: one tier involves architecture strategy and goals, definition of elements, standards, and the other architectural goals. The latter tier involves funded projects either through architecture, acquisition or implementation. Even though management may want both tiers to interdependently function, the two tiers are related, yet distinct processes. For example, at corporate headquarters a chief architect or central architecture group along with solution architects are assigned to projects. They build systems and implement technologies and standards. Usually, the business unit that funds a project has the most influence. The behavior associated with enterprise architecture is similarly related to the organization and processes used to achieve the goals of REST:

  • architecture compliance
  • portfolio management
  • budgetary compliance.



Don’t think managing your REST implementation operationally is enough. Keeping tabs on execution does not ensure the service is really supporting overall business goals. Traceability to business goals/priorities through EA to SDLC to operations make REST implementation successful in the enterprise. Equally important, do not minimize organizational influences that are needed – monolithic, project-centric funding models are not likely to work in the world of REST.

Booker Showers

Page 1 of 512345