Adopting, designing, and governing SOA well

SOA Best Practices Digest

Subscribe to SOA Best Practices Digest: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get SOA Best Practices Digest: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

SOA Best Practices Authors: Jason Bloomberg, Andy Thurai, Charles Araujo, Hollis Tibbetts, Pat Romanski

Related Topics: Agile Software Development, CTO Journal, SOA Best Practices Digest, SOA & WOA Magazine, Telecom Innovation

Televation: Article

What Is Service Orientation?

On the importance of achieving true business agility

Horizontal vs. vertical partitioning

Turning companies into plug-and-play businesses is easier than re-engineering in some ways and more challenging in others. It’s easier because it doesn’t have to be done in a big bang, and rolling out architecture capabilities in small stages provides three incentives to thrust – a quality imperative to any change management process, namely: [8, 12]

  • It can prove to management that the architecture will perform as promised early on.
  • It avoids overwhelming managers and users with too much automation all at once.
  • It enables technicians to quickly address any issues as they arise.

Often companies uses this migration pattern (or a similar one), but they partition the work that needs to be done horizontally, not vertically.

The liability of the horizontal approach is that it focuses on the technological layers (f.ex. the different tiers) and is therefore technology driven, whereas vertical slices are oriented around use cases that is, business driven. [11, 14, 16]

Figure 4: The difference between vertical and horizontal partition of work
Figure 4: The difference between vertical and horizontal partition of work. [11, 14, 19]

Another common fallacy in enterprise-wide architectures is that you can achieve economies by doing things in large scale. The theory goes that if enough people are doing a large-enough project, there are inevitably going to be many redundancies. The elimination of those redundancies results in reduced development and maintenance costs. The larger the project, the more redundancies. The more redundancies, the more opportunities for redundancy elimination. The more redundancy elimination, the lower the overall cost of the project. [14]

Unfortunately, this theory ignores an even more basic law of project management: the law of diminishing resource returns. The more people involved in a project, the less efficient the project as a whole becomes. The law of diminishing resource returns is a corollary of the famous Brooks' Law.5 [3, 14]

A relatively small group attacking a well-defined partition of the enterprise can do a reasonable job in a reasonable timeframe. A large group attacking a non-partitioned enterprise may indeed find redundancies. But the cost of finding those redundancies, arguing about how best to eliminate them, and trying to agree on a design for a unified approach will, in almost all cases, far surpass the cost of the redundancies themselves. [14]

It is true that economies come in scale. But true economies come in small, not large scale. [14]

A horizontally partitioning has the benefit of approaching the company in a holistic manner which facilitates optimisation of the architecture. This might be a reasonable approach for smaller companies that have less legacy – either grown organically or inheritance-by-merger. For larger companies, this is not a suitable approach for two main reasons:

  1. Project sizes are substantially bigger and therefore require more planning and resource allocation which in turn increases risk above the benefit of a holistic approach – that is, the optimisation becomes premature, and should accordingly be tended to at a later point.
  2. Modern companies evaluate performance in quarterly business cycles which doesn’t lend itself to projects exceeding the cycle magnitude.

Examples of horizontal approaches are building a complete process orchestration in one project cycle or building all services interfaces, while an example of a vertical project is cutting the orchestration and service interface in orthogonal slices and developing these ordered by priority (see figure 4).

Think strategic, act tactically

Figure 5: Actions within an enterprise.
Figure 5: Actions within an enterprise.

The best of best practices for companies strongly suggest the following rule: while adhering to the strategy to gain long-term benefits, act tactically to gain thrust into your projects and stay performant through each business evaluation cycle (for instance through modern quarterly cycles).

It also suggests the following three key points: [6]

Firstly, focus architecture efforts on key business processes. Architecture exercises that attempt to establish links among applications, data and infrastructure for all of a company’s business processes will almost certainly stall. Focus on just the core ones.
However, this doesn’t mean you shouldn’t pick the low-hanging fruits. That’s per definition always a beneficial ROI-positive move.

Secondly, don’t skip or rush through stages. Skipping stages lead to either failures or delayed benefits. Companies benefit more from making improvements in their existing stage than from transformational efforts that abruptly move them into foreign waters.

Thirdly, recognise that complex organisations have multiple architectures, which may be different stages. Because these different architectures have different objectives, they will likely be at different stages.

In order to identify and compose a roadmap for an architectural platform for growth, it’s necessary to know what the baseline looks like and what gaps must be overcome to reach the goal.

The following three steps outline the design requirements for such a pilot project: [4, 21, 22, 23]

  1. Business-to-technology model mapping. A to-be model of business (i.e., a model of the business as we wish it to be) is mapped to an as-is model of applications (i.e., a model of applications as they are today) to identify areas of redundancy and overlap, and to provide a basis for tools that can help derive technical requirements from business requirements.
  2. As-is pattern discovery. A to-be model of software interfaces is compared with an as-is model of composition and flow of legacy applications. The analysis identifies instances of structural patterns in the architecture of legacy applications, the programming, and the data representation that define the gap between the as-is implementation model and the to-be implementation model.
  3. Transformation pattern selection. A set of patterns for transforming legacy applications is compared with the model gaps and the as-is patterns to identify approaches and techniques for closing the gap. The transformation patterns provide solutions that allow the gap to be closed over several iterations. The transformation patterns include structural patterns for changes to application architecture, programming, and data representation, as well as process patterns for the transformation work itself.

Notice the strong correlation between these steps and the general architectural method. It’s perfectly reasonable to reuse existing change management project methods to execute this pilot project, as they are all based on the same foundation as the generalized architectural method. [5]

5 Frederick Brooks (1931-) is a software engineer and computer scientist. Over 30 years ago, he first observed that adding more resources to a late software project only makes the project later. For this and other observations he was awarded the Turing Award in 1999.

More Stories By Martin Kaarup

Martin Kaarup began his professional career over a decade ago as a system developer on location-based mobile phone services. During that time he participated as lead developer in pioneering unique state-of-the-art location-based services for the European and Asian markets, such as low-cost fleet-tracking using antenna triangulation and applications for utilizing customer positioning data for demographic use. He also participated in building location based games, such as treasure hunts and country-wide Dungeon & Dragons-based games merging www, wap and sms technologies.

Later, he shifted to the financial sector in Scandinavia where he worked as an enterprise architect building, extending, and delivering advanced fund data solutions and services designed specifically for the pan-European Fund Industry.

Today, Martin is an employee at the Swedish consultants company Avega Group, where he focuses his expertice on consulting companies on strategic and enterprise wide issues.