We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Anatomy of Agile Enterprise

Janne J. Korhonen

SOA Not?

Vote 0 Votes

Service-Oriented Architecture (SOA) is touted as a "must have". Cherish it, or perish, says the IT analyst, as if SOA could be attributed some absolute normative value. However, SOA, as a technology, does not bring about business agility. In fact, deploying a SOA stack in an organization that is not agile to start with may be seriously misguided and downright detrimental. At worst, SOA does not disentangle the technology mess but only creates new nightmares at just higher level.

In an earlier blog post, I have discussed the implications of Service-Dominant Logic on IT. As the overall business perspective is shifting from the relatively stable, closed and controllable system of a self-sufficient enterprise to the relatively fluid, open and transformational system of networked co-adaptive entities, so is information technology moving from centralized, siloed, proprietary and monolithic enterprise information systems to peer-to-peer, service-oriented, standards-based and modular inter-enterprise composite applications.

However, different industries are embracing the new dominant logic to varying degrees. Not all markets are dynamic. Not all businesses need to be the most agile. Traditional business-IT alignment works reasonably well in relatively stable and predictable environments. As illustrated in Figure 1, the cost-benefit balance of IT investments within Goods-Dominant Logic favors traditional IT -- up-front investments in business technologies may be "technological overkill".

In complex, competitive and non-linear business environments, in contrast, new business technology is imperative; otherwise there will be "technological deficiency". A more encompassing approach to enterprise governance is called for -- one, in which business and IT converge. Change must be addressed from the constructional perspective that entails coherent and consistent design principles and holistically integrates various business and organizational aspects. SOA underlies this convergence and integration but necessitates an agile organization.

Figure 1. Requisite alignment of business and technology.

Neither technological overkill nor technological deficiency is desirable.

At any rate, the general trend is towards increasingly complex and competitive business environment across all industries. Even the organizations that can still afford to follow Goods-Dominant Logic must take deliberate steps to increase their "absorptive capacity" by building higher-level organizational and IT capabilities in step with the increasing market dynamism, lest they be fallen to technological deficiency. Failure to increase the capacity requisitely is likely to lead to a self-reinforcing "lock-out" from further technology adoption.

As discussed in my previous blog post, the focus of IT is shifting from mere information systems development to systemic competencies and more encompassing enterprise engineering. To fully harness the power of business technology, the entire organization ought to be recast according to the overarching service strategy that permeates its every facet.

Technological overkill may also give rise to misapplication of business technology. If the organization works from its traditional, functional stance, the technology tends to be applied according to the same outlook. A case in point is BPM (Business Process Management) that is said to be the "killer app" of SOA. However, BPM runs the risk of killing the agility that it purports to achieve. Only a fraction of processes are rigid enough to allow themselves to be "managed" through BPM. Most business processes are considerably varied from time to time and would require the very degrees of freedom that imperative BPM eliminates. In many cases, informating rather than automating processes would increase agility.

IT infrastructure vendors want to sell you SOA, or if they cannot sell it, rename it and try again. However, SOA cannot be bought. It also cannot be built in a one-off development project. SOA pertains to a fundamentally new way of conducting business and calls for sustained organizational learning to adopt a new worldview altogether.

SOA not? Not if you are not ready. Think big, but start small. Create your service strategy and build the SOA roadmap that integrates business, organizational and technological aspects. Establish enterprise governance and align enterprise architecture therewith. Develop pertinent capabilities. Only then invest in technology to the requisite extent, avoiding the stalling with technological overkill as well as the foundering with technological deficiency.

1 Comment

Interesting post. While composite applications are the future, I agree that SOA done wrong is just an expensive new form of spaghetti. I agree with your 'Caveat Emptor' advice.

I think it's also worth noting that breaking closed monolithic applications into closed encapsulated services and distributed components solves some problems while introducing new ones (indirection, latency, governance, middle-ware expense, etc.).

Independently evolvable parts are an advantage, but changes to interfaces, even non-material changes, can break operations of dependent apps(apps don't co-evolve with their constituent services), which can lead to entropy.

Re-usability is generally low as generic services are less relevant to business, and specialized services are less re-usable.

Moreover, encapsulation of data constrains run-time dynamics, which limits value of composite apps, particularly for information-intensive applications.

It's not that SOA has no value, it just pays to know what you are getting into.

PS: Thanks for the reference to "Informating". I wasn't familiar with the term though it appears to describe our own approach quite well - Breaking processes into activities and information and dynamically evaluating interactions for applicable policies.

Janne J. Korhonen provides insights into how information technology can be applied strategically to catalyze organizational change and responsiveness. Drawing from both theory and practice, he discusses agile enterprise and its governance.

Janne J. Korhonen

Janne J. Korhonen is an independent business and IT consultant,specializing in enterprise architecture, business process management,service-oriented architecture and pertinent governance models. He has over ten years of experience as an architect and consultant in a variety of extensive and mission-critical IT projects. With strong theoretical underpinnings, his consulting encompasses systemic co-development of business, organization and information technology.

Recently Commented On

Recent Webinars

    Monthly Archives