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.


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

What I would like to see in a Sales Force Automation Tool

What I would like to see in a Sales Force Automation Tool



Accountability begins with an open environment. Open environments help motivate. When everyone on the sales team can see the contributions of each other, the natural result is more productivity. On the other hand, a lack of information allows less motivated people to remain hidden.

Sales Management

Sales Management should provide managers and representatives with the capability to easily log and track leads, opportunities, and sales orders. In addition, capability should permit managers to run opportunity and revenue forecasts using criteria such as step, status, source, demographic, sales reprentative, and company.

Moreover, allow sales personnel to build complex profiles and assign diverse criteria to each contact and/or company. I would like to forecast project commissions with varying degrees of granularity.

Tie e-mail, reminders, and opportunities together as one unit.

Wouldn’t it be effective if Sales Management captured sales leads and put a follow-up system in place? Such functionality is essential to generating consistent revenue growth. Most sales people are very busy managing relationships and potential sales, which can lead to some prospects falling through the cracks. What if there was a proactive e-mail reminder system used in conjunction with sales management to keep sales people on track?

In the mobile world, having access to possible leads is part of the picture. Seeing every lead with the probability of closing the sale is something entirely different. Without the context of probability, real-time sales forecasts can be difficult. Give sales managers the ability to confidently make forecasts on-the-fly, at a moment’s notice.

Sales Management, Teamwork and Collaboration

A lack of individual accountability often stems from poor systems allowing people to hide poor performance. An open environment, where everyone can see what everyone else is doing, goes a long way to promote a sense of teamwork, while uncovering productivity problems. Optimal systems ensure strong performance is rewarded, and uncovers poor performance.

The accessibility of mobile-based, detailed notes related to phone calls or meetings will also increase effectiveness. All the voice recognition software available makes this functionality doable.


Associated documents should automatically appear given the amount of data mining tools available.

Understanding sales processes should be self-guided by the software; forecasts and funnels are intrinsic to a successful sales and marketing strategy. Software should be able to offer complete collaboration between sales representatives, managers and partners.

Is every functionality I have described too much to ask of an integrated Sales Management tool? Why do I need to open up various apps and modules to get a complete picture of the sales pipeline?

Certainly, in the post-PC age we can do better than the tools we have now.

Booker Showers

Production Best Practices

A programmer should not expose resources within a REST initiative in a “bottom-up” ad hoc manner. Bottom-up development is inherently driven by immediate project needs. For example, how you solve a specific problem with a specific implementation (often driven by the influence of existing applications and associated behaviors masquerading as true business requirements).

What happens when an organization defines and implements REST with the mindset described? The REST implementation simply becomes layered with more spaghetti code of a different form that does not improve business process flexibility. Consequently, a monolithic application in a different technology is implemented often with disappointing results.

To achieve success, a programmer should not define REST in a “top-down” manner. Top-down business process analysis can lead to either “analysis paralysis” – continual refinement of a model hoping to reach perfection (which never comes), or “Big-Bang” projects – trying to define and implement everything at once. Either approach usually creates disastrous consequences (a combination of “death march” projects, and cost, and schedule overruns).

What do organizations need to make progress? A coarse-grained business model driven by key business processes. Not all key business processes may apply but definitely a representative set of high-priority processes to start. Architects and business analysts should collaborate to build an applicable model by extracting key business processes to define a normalized set of functions. Next, group functions together based on behavioral affinity as a straw-man set of initial, target resource definitions.

Resultantly, we have a useful framework for the “real work” – detailed analysis, design, and REST implementation needed for our current set of prioritized projects. Based on business process (and project) prioritization, we identify the needed resources from our business reference model and formalize the definition for the prioritized resources. Ideally, each resource should be driven by requirements extracted from at least two separate processes. Designing a REST resource based on a single use case may result in a fragile, and narrowly defined implementation lacking the flexibility necessary to meet the next set of prioritized projects. Formalization efforts are likely to result in modifications to business architecture – which is fine! We can iteratively enhance the architecture as progress is made towards a successful REST implementation.

Booker Showers

Time Management

The Corporate Sonata – Time Management Strategy


(A Time Management Strategy)

Without a Grasp of Fundamental Principles that Drive Companies You Burn Money

When employees are organized and in control of each detail, a business operates like a classic sonata. Companies need business management systems that link to employee time management and personal information tools.

Time Management Strategy with a Groove

Time management systems should automatically integrate with each employee’s personal device. For example, when a manager delegates a task to an employee, does the task show up on his or her computer, tablet, and smartphone? Or, when management launches a project, does each team members’ tasks display and automatically update project details? If not, your company is only faking a time management strategy.

The Activity Waltz

Creating a corporate sonata means each employee through his or her time management system gains access to real time information to help effectively perform tasks. Tasks or activities are the backbone of our time management strategy. To focus on activities is important because instead of assigning activities to a project, our strategy is to flip this concept and start at the granular activity level. By first focusing on the activity we eliminate the disconnect between calendar programs, project management programs, and billing programs.

Tune Data Mining

Often ignored is how current activities affect future endeavors. We show you how to effectively use data mining to avoid the pitfalls that make a company less nimble and adaptive. Our strategic perspective prevents companies from developing paralysis at time when constant movement is crucial.

Booker Showers


5 Rules For Creating New Versions

I marvel at the debate that takes place about when to create a new version of an API, HTML, or REST resource. In a world where being combative or argumentative is the norm, here is some guidance and ammunition for those looking for sanity when creating a new version.

Parameters Change

Any time a parameter is added or changed on the input or output of a method, the version should be changed. The version change is also a courtesy to developers utilizing the method—hey something was added or changed, so take note.

Methods Change

When a method changes either through a name change, additional functionality, or through deprecation a new version, is necessary.

Location Change

Sometimes it’s necessary to move a method or REST resource to a new location because of an architectural, semantic, categorization, or physical server consideration. When the location of an API method changes, always create a new version and add a warning to the existing API method that the method was moved to a new location, and all future calls should be directed to the new location.

Technology Implementation Change

Technology changes. Frameworks, languages, and new programming techniques are often catalyst for changing the implementation of an API. The changes usually result in a speed increase, better quality, or more functionality. When the technology used to implement a technology changes, it’s a good idea to inform the user via a version change.

Results Change

There may be times when the results returned from a method call are augmented or modified but are not useable. For example, if the results expected are for an address of 50 characters, but the results now include 70 characters and an office suite number the calling programs may not be able to handle the result.

To execute a successful implementation, you must have a practical versioning scheme. Without a versioning strategy, an API and the associated functionality becomes difficult to scale and deploy.

How to Manage Business Processes Using Facts

How to Manage Business Processes Using Facts

Effective decisions and appropriate actions result from high quality, complete information. A system built from the ground up with a single purpose (to integrate) can profoundly affect the way a business operates. Integration dissolves barriers to communication, reveals opportunities for revenue growth, and helps reduce or eliminate expenses.

A significant operational challenge lies in identifying how to help employees perform tasks better, and faster, using fewer resources. How to Manage Business Processes Using FactsHowever, today’s internal systems are growing exponentially while becoming more fragmented. Extreme difficulty is developing within organizations to create a clear view of the business. A real-time view for large organizations is impossible because management only receives small bits of information from disparate systems that require business analysts to interpret. The disparate systems must connect to create a complete business view. A business does not effectively operate without the facts that represent a true understanding of the business and its challenges.

An important determination often overlooked when a company adopts a new system is “will the system play well with others.” Too frequently, a new system does not play well with existing systems, which is why integration should be a vital part of any IT strategy. To enable a company to run like a well-oiled machine, the parts must move in complement. When one part moves, the other parts should produce complementary reactions.

Large organizations usually suffer from departments operating as silos instead of functioning in information-sharing, reciprocal ways that benefit the entire organization. Staff invest considerable time  gathering information within various departments to create reports to present to Executives. The information gathering process is time consuming, prone to errors, and often information is outdated by the time Executives are informed. Consequently, management will make decisions based on guess-estimates, and gut feelings instead of real time facts.

Don’t leave system integration out of your management strategy. Yes, system integration is IT focused. Nevertheless, a clear understanding of an entire organization is only possible when system integration is considered a vital component of business process effectiveness.

Page 1 of 212