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

Real Time Strategy

Operate in Real-Time – A Mobile Real Time Strategy


The importance of  a “real-time enterprise” discussion is to distinguish between objectives and reality. Few organizations are prepared at the enterprise or technology level to operate in real-time, or close to real-time. Most organizations have latency built into the business caused by internal and external factors. For example, the supply chain, existing processes, employees’ mindset, and policies. Every factor of an organization deserves scrutiny when the goal is to efficiently operate. To become a real-time enterprise takes a great deal of time, resources, and political will to re-engineer an entire organization around a real-time mandate.

Information systems are beginning to deliver on the promise of real-time operations through improvements in the performance of hardware, networks, and software. Further, organizations and individuals investing in mobile communication technology expands opportunities for collaboration in real-time.

Generally, an organization has the hardware and enterprise systems in place to complete tasks. However,  gaining competitive advantages is only a result of reducing the time it takes to collect, analyze, and redistribute data.  The evolution of the mobile worker is an ideal catalyst for crystallizing performance improvements into true business advantages. So, how do mobile devices help to achieve real-time operations? Real-time operations is not about implementing one more system or one more device.

Adding intelligence and integration to information and systems in which an organization has already invested, and creating channels that allow users to take advantage of available intelligence is the essence of real-time.

Comprehensive information and integration

In today’s data-rich market environment, an organization or an individual making decisions without adequate information operates at a significant disadvantage. Out-of-date information leads to poor decisions and missteps. Not having access to appropriate service interfaces result in critical delays, or incomplete tasks. In many cases, the right information and processes lie beneath layers of software and systems requiring excavation. Comprehensive information and integration should be the norm.


For example, real-time information delivery can provide an actuary claims information from a data center in California, mixed with financial performance benchmark data from New York, and cost of sales information from Boston. Additionally, elements of a transaction interface running on a New York mainframe, can also be included in the actuary’s information set.

Moreover, a mobile-based strategy is the ideal mechanism to deliver heterogeneous electronic assets to users. However, to deliver to mobile users requires enhanced coordination and effort to connect existing systems, transform data types to web-ready,  and mobile copy, and manage each transaction until completion. Do not underestimate the complexity of this first requirement, nor the number of systems mobile users need to access daily. Do not forget things change – as soon as one business scenario is worked out, the systems, people, or requirements change.

The nature of today’s business environment is constant change. A sophisticated, well-planned mobile strategy offers the unique ability to access and manage structured or unstructured content, no matter if the content resides in ERP, CRM, HR, documents, or legacy systems.

Ultimately, your organization’s challenge is to establish a flexible strategy that adapts to various formats, standards, protocols, and systems within your organization.

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

Page 1 of 512345