Profitability, Revenue Growth and Process Standardization

It is often necessary to give up short term profits to maximize revenue growth. Introductory discounts, special offers and other incentives are very common methods for getting new customers.

Most organizations use another strategy to grow revenues, they empower customer facing business units to serve the customer in special ways. This is often very effective, but the result is often a proliferation of products, services and behaviors. This is not usually the most efficient way to use corporate assets and therefore represents a choice to increase revenues at the expense of immediate profits.

For IT managers, product and service proliferation creates problems. In many cases the result is either no support at all for many business processes or an attempt to impose a poorly suited 'enterprise' solution on all business processes.

To achieve efficiency, but avoid constraining revenue growth, managers need to recognize the nature of the tradeoffs involved. Often, the situation may be temporary, which also affects decision making.

Business managers and executive teams are really the ones who need to own the decision making about how to support business units with automated systems. Decision making needs to reflect the fact that there are costs in supporting diversity in product and service offerings, but also the fact that while process standardization may reduce costs and therefore increase profits, it will often result in reduced revenue growth.

Worst Practices in SOA Implementation

In a September 2003 HBR article, Why Hard-Nosed Executives Should Care About Management Theory, Clayton Christensen and Michael Raynor state that many managers accept generic business advise which they expect to work in all circumstances. Similarly, many IT managers accept the advise that application of SOA will solve their problems.

Christensen and Raynor, go on however, to state that all theories have their flaws, and that a theory becomes more powerful as these flaws are uncovered and resolved. This insight can be applied to the theory of SOA as well.

In this context, I came across a white paper from iWay Software named Worst Practices in SOA Implementation. In it, the author identifies the practices that lead to SOA failures:

• Overemphasizing low-level code
• Centralizing design and development
• Ripping and replacing legacy software
• Buying software without support

The paper goes on to explain why these practices are bad, and how to resolve them. The author makes several good points. One is that companies need to abandon an EAI mindset, and not use SOA to create EAI workflows. This just leads to low level code which is both too complex and not reusable. Another good point is that service creation and maintenance should be distributed to local domain experts, not a central design group. This is consistent with my view that SOA is primarily an architecture for dealing with distributed, independent systems.

Although an interesting list, the paper includes some typical vendor bias, and is incomplete. A more complete list might include:

• Data is not organized and managed on an enterprise basis
• Service governance is not duly considered
• Unnecessary technology such as an ESB
• Technical rather than business focus
• Service design consistent with process rather than service workflows

The idea of exploring failure in order to understand where and how SOA should be used, seems to me to be a valuable approach and worth exploring in more detail.

See also Steve Jones excellent article on SOA anti-patterns.

Design Considerations for a Service Component - Utility Services

In an SOA system, a service component which implements a service, is similar to a small application; it has to do many of the same tasks an application does, such as security enforcement, data management and service management. Service components may therefore, like applications, call on services to complete some tasks. For example, a service component can call an audit service, in order to create an audit record.

These types of services are usually called utility services. Here is a partial list of utility service types:

• Authentication: Verify the credentials provided by the requesting agent
• Identity: Use the identity of the requesting agent
• Personalization: Retrieve, update and apply preferences of the requesting agent or person
• Access control: Control access to resources based on policy
• Encryption: Encrypt/decrypt and sign messages; manage keys
• Provisioning: Grant or remove access to a resource or service
  
• Master data management: Access and update master entities (customer, product, account, etc)
• Rule execution: Execute business rules
• •
  •Auditing: Record audit events
• Logging: Record events useful for debugging and system recovery
• Service management: Set and manage service levels based on policy
• Error management & reporting: Handle and report errors
• System monitoring and notification: Monitor service and raise notifications when thresholds exceeded

Some utility services, such as access control, can be fully or partially provided by the SOA runtime. However, in many cases utility services must be called directly by a service component. If the service is distributed and uses a web service implementation then qualities of service such as reliability and performance, tend to decrease. In object oriented systems, utility services are provided by in-memory objects or local components, so this is not an issue. In the SOA era, we can still use local libraries, to accomplish a task but its not as flexible as using a service and introduces platform coupling.

There is no easy solution to this problem; in a sense SOA has just pushed some of these problems down a level. For now, I suggest building two versions of each service: a fully distributed service and a local component which can be loaded directly into memory by a service component. Yes, this is not fully satisfactory, but it is at least one step forward.

Taxonomy and Classification of IT Assets

One of the most useful ways in which to improve asset and policy management of IT assets is to classify them based on a well organized schema or taxonomy. When this is done, the benefits include:

• Since similar classes of assets tend to have similar structures and behaviors, accurate predictions can be made about the behavior, characteristics and the life cycle of assets.
• Asset planning is simplified.
  
• Policies can be defined and shared for assets which reside in the same category. Policy administration, monitoring and enforcement is therefore simpler and more efficient
• Skills and resources can be shared if asset similarities are recognized. Training can be optimized as necessary.
• Transparency and visibility of IT assets can be achieved. Accounting, security, governance and risk management are simplified
• Designers (and system vendors) can discover and understand the policies that apply to the selection, purchase, modification and creation of assets
• Impact and dependency analysis is easier to carry out
  
• Increased asset interoperability is possible, leading to lower integration costs
• Assets can be rationalized. Asset utilization can be increased, since asset sharing is more likely

A taxonomy provides a vocabulary for the classification scheme, a relationship schema between categories, and a membership test for assets. A taxonomy is a good one, if:

• Categories are organized and related in intuitive and natural ways.
  
• Names, conventions and rules are simple and consistent.
• Barriers to use are low.
  
• Errors in classification are difficult to make. Membership rules are clear and easy to understand.
• There are significant policy differences that apply to an asset because of the difference in classification.

There are several common errors when taxonomies are created. These include:

• Categories exist with no significant differences between the categories. Membership rules do not lead to important differences in behavior or properties. For example, the color of a computer has no impact on its behavior.
  
• Categories exist which have no policy differences. This leads to policy duplication and inconsistency. This is the same problem as the first point.
  
• Failure to recognize significant differences between assets. For example whales were classified as fish for a long time before this was corrected.
• Membership rules in a category are ambiguous or incomplete.
• Incomplete schemas. Some assets cannot be assigned to a category.

No taxonomy is perfect, but if there are many problems with a taxonomy, then policy definition and enforcement become difficult. If enough policy exceptions and workarounds occur, then policy usually falls by the wayside, and decisions are made on a local adhoc basis, rather than using a managed, disciplined and standardized process.

Achieving Value with Planning

Project planning is pervasive and widespread in the IT industry, but there is a common misunderstanding of its real value and purpose. Meeting the project schedules and timelines is all too often seen as the only measure of project success. The result is that planning becomes extremely conservative, project budgets are bloated, standards are kept deliberately low, and project decisions are driven by project plans rather than by sound business reasons.

Good planning is primarily about informing the plan authors about objectives, resource requirements and risk. Only when planning is thorough, is it possible to understand what these really mean. Without good planning it is hard to understand what should be done and who should do it. For example it is common practice in movies to plan a scene in detail, because that is the only way to assemble all the crews and equipment necessary to actually shoot the scene.

Plans do help predict the future, but their value lies in getting the most out of resources and making adjustments as necessary when planning assumptions fail (which is the norm). Aggressive but realistic planning assumptions allow projects to be staffed with small, lean teams; resources are allocated to projects only when needed or when failed planning assumptions require a boost in resources.

For the highest staff utilization, best practice is to plan so that half the projects will exceed their initial estimates, but to compensate by maintaining a reserve of skilled staff which can be allocated to projects as necessary. This allows organizations to achieve both low delivery cost and timely delivery.

Lean teams are only possible with good planning. Otherwise, it is difficult to know when and how to make adjustments in time to meet customer commitments or to adjust for risk actualization. Some customers may also be willing to trade off delivery dates for lower prices, if they are given the choice.

Common industry practice is to lock up excess resources early in a project. This means either that the project is carrying unnecessary people OR it can't start because the people required are just not available. Organizations which can use planning as described have a decisive, strategic advantage which cannot be easily duplicated.

IT Metaphors

Metaphors are powerful concepts that help organizations understand what they are doing and what they need to do well. The right metaphors can be extremely helpful, but the wrong metaphors can hurt.

IT organizations often use the wrong metaphors. To illustrate, consider the automobile industry. There are manufacturers, dealers, customization shops, repair shops, insurers and many others. On the customer side, there are individual buyers and fleet buyers.

Each of these organizations has a different focus, set of goals and performance measures. Manufacturers, for example, have to deal with challenging design and vehicle construction problems. These require a very complete and disciplined process. On the other hand, a fleet operator is charged with purchasing vehicles from manufacturers and dealers that satisfy the demands of the business users of the fleet. Fleet operators need to manage the fleet to keep the fleet in a good state of repair. Major and minor repairs as well as custom jobs are performed by fleet mechanics in their own repair shops.

Fleet management, is very different from manufacturing. Why then do IT organizations act as if they are in the manufacturing business rather than the fleet management business? IT organizations often have elaborate software development processes, showing how to build systems from start to finish. The processes for purchasing new systems, selecting a technology or keeping existing systems in a good state of repair are seldom as complete.

IT shops need to change their dominant metaphor and act like they are fleet managers, rather than manufacturers of systems. This would help focus on the real problems in IT today, systems which fall into a state of disrepair and don't serve the needs of the business