SOA, Services and Business Architecture

At the end of May, I will be participating in an IBM sponsored conference - Impact 2007.  The conference will focus on Service Oriented Architectures (SOA), " ...  a business-centric IT architectural approach that supports integrating your business as linked, repeatable business tasks, or services."  SOA is being embraced by an increasing number of companies because it helps them build a more flexible IT foundation that can respond quickly to rapidly changing business conditions and user requirements.

There are many ways to view SOA, but to me its most compelling features are the introduction of standard, modular, interchangeable components to the world of software.  This enables developers to build composite applications by drawing upon pre-defined components from multiple sources within and beyond the enterprise.

The introduction of standard, interchangeable parts was one of the critical innovations that helped bring about the Industrial Revolution a couple of centuries ago and ushered in the concept of mass production in many different kinds of industries.  Modern engineering practices - especially those used for developing complex systems or objects like airplanes, bridges and microprocessors, - are built around the concept of standard, modular components.  Such components are a pre-requisite for sophisticated tools like those used in Computer-Aided Design (CAD) and Supply Chain Management. 

These kinds of advanced engineering, mass production, and similar capabilities have brought large productivity improvements to the manufacturing of physical goods in countries around the world.  However, in services - which in advanced economies like those of the US, the UK and Japan account for roughly 75% of GDP and a similar percentage of the labor force - productivity improvements have been significantly slower.  This is largely because in the people-intensive service sector of the economy, we have not been able to bring to bear the kinds of engineering and production capabilities that have been successfully applied in manufacturing, including standard, modular components and engineering-based tools and processes.

It is interesting to note that while services represent the dominant part of the economy, its exact nature is poorly defined.  I like the simple and powerful definition of services given by INSEAD emeritus professor James Teboul in his recent book Service is Front Stage: Positioning Service for Value Advantage.

Every organization, whether in business, government, health care or education consists of front stage and back stage activities.  Services deal with the front stage interactions; manufacturing and production with the back stage operations.  People are prominent in front stage activities, where the focus is on providing solutions to problems and on achieving a positive customer experience in a collaboration between the providers and consumers of services.  Product excellence and competitive costs are key to back stage activities, which tend to focus on specialization, standardization and automation.  Given this definition, every business and institution is involved in services to a greater or lesser extent, because its activities will involve front stage interactions as well as back stage operations.
 
Over the years, we have been quite successful in applying IT to automate the back stage activities or processes of the business - transaction processing, credit card checking, payroll, and so on – because their relatively standardized, repetitive nature is amenable to the application of technology and engineering principles.  However, we have not done nearly as well with the people-intensive, front stage aspects of the business.  Even when we have tried, such as with Enterprise Resource Planning (ERP) processes, many people find the ERP applications we have designed too complex, monolithic and inflexible.

I think that the main problem with many such software applications is that they have generally been designed around software engineering concepts, and the structure of the applications thus often reflect the underlying IT systems they are built on, not the underlying business concepts they are in principle supposed to support.  This is quite different from the top-down design approach in more mature disciplines like, say, aerospace engineering, where the designers always have in mind that concepts and components that are related to airplanes, which they then develop using CAD tools and extensively simulate and test before proceeding to manufacturing.  All along, airplane architects and engineers have a pretty good model in their mind of the airplane they are designing.
 
SOA has been gaining ground as an effective mechanism for defining business services, the software that implements such services, and the software-based tools that enable people to effectively take advantage of them.  Unlike traditional software, SOA is based on modularity, composability and interoperability.  It encourages the designers of business applications to make sure that the services, components and overall architecture they are defining properly represent the business view, and not the view of the underlying IT infrastructure.

The hope is that with SOA and the many different tools developed around it we will be able to design, simulate and test business services in business terms - prior to their implementation in IT systems.  Such architectures would then be much more reflective of the basic concepts of the business - be it a hospital, a retail distribution center, an industrial organization or a government department - rather than those of the IT foundations on which they are being implemented. 

This is very challenging for a variety of reasons.  To name one, there is no tradition of architecting, designing and simulating business services and business systems.  It has all been done in a relatively ad hoc, labor-intensive way.  This is not unusual, as every discipline that is now a well established engineering discipline - civil, mechanical, electrical, and so on - went through such a transition decades ago.  But eventually the industry starts settling on a suite of standards and modular components, sophisticated tools are developed as well as the ability to extensively simulate and test various design options, and a more structured, engineered discipline starts to emerge.  This will come to business architecture as well over time, with the help of major software technology innovations like SOA.

Through experience, we have learned the limitations in our ability to leverage IT for quintessentially human tasks, no matter how fast our computers have become.  But this is now beginning to change.  I really believe that bringing technology and engineering principles to all facets of business, as well as healthcare, education and government is one of the most exciting opportunities in the future, and is among the most fascinating set of problems that will challenge our best and brightest.  It promises to transform the very nature of enterprises, industries and economies.  This is truly one of our grandest challenges in the 21st Century.

Comments

[Padmanabha Rao]

I followed the blog until the last paragraph. It seems to me that SOA (or any other paradigm) could set itself up for disappointments precisely because its conceptualisation comes easy to our mind. Isn't it true that the gap between what we can conceive of business/culture in the abstract in our heads and what can be accomplished by digital electronics is unbridgeable -and therefore a more realistic framing of SOA or SaaS etc would be in the best interests of the DT/IT/KT industry?

Padmanabha
Bangalore

[Martin Hromek]

Just a minor comment: Isn't it true that modularity and interoperability are the necessary prerequisites for composability/orchestration?

[Padmanabha Rao]

Martin,

It's not about modularity as much as about composability. Defining the module would still be binary.

The question is not whether one can compose a '4' out of four '1' modules or eight '0.5' modules. It's how do you ensure the composability of '4' by any of the various combinations (and perhaps permutations) of modules.

SOA is the mother of all concepts. Being On Demand requires hard work, much of it inside people, outside the realm of digital technology. SOA would be realistic to the extent it focuses on supporting the required development of that outside part, I think. The more SOA is expressed in terms of digital technology, the less it achieves by way of actual transformation.

For ages, people have been blaming Pakistan to be the...