When is the last time we’ve seen truly new thinking in the area of Architecture for business and IT systems?  Zachman Framework, 1984?  TOGAF, 1990’s?  OMG Model Driven Architecture, 2001?  Has there been any breakthrough thinking other than to continue to provide more clarification and more decomposition about how to document enterprise and IT architecture?  There has, but change is painful even for a profession that prides itself in facilitating change.

Joe McKendrick had a blog post a while back that asked Do SOA and Enterprise Architecture now mean the same thing? I’ve said in the past that cloud is also very dependent on good EA (at least above to IaaS layer).

I personally view that EA is about the alignment of enterprise business goals with technological initiatives from an end-to-end perspective.  SOA is about the assembly of functionality from services is definitely impacts the Enterprise Architecture as it’s defined but is a subset. Going forward I firmly believe that it will take on a great portion of the EA as more of the items that used to be in the EA are hidden in services coming from SaaS vendors.

Getting the most out of the cloud is definitely one of the roles that EA will need to take on. All these different buzzwords do address the issue that businesses expect differentiated value from their IT systems and at the same time lower costs and higher quality. These techniques will all need to come together to make that happen going forward.

Recently there have been a number of blog posts again that have been talking about the death of SOA (again!). As I look around, the death of SOA discussions started way back in January of last year. Back when we were starting this blog, I did a number of entries around service oriented architectures - but that was half a decade ago. Sure there were some fad-like tendencies around SOA just like there are around Cloud. I'd state that SOA was a pre-requisite for cloud to move beyond IaaS.

It does remind me of a situation back when I was at a large non-US government client in the late-90s who said "What about that whole object oriented buzz a few years back, whatever became of that." In that case, it was that OO was so omnipresent that it was indistinguishable in the technology they were using. It was just part of the way things were. I believe SOA has entering that same situation. The techniques are now everywhere, therefore it is a non-issue.

At least it is not the other situation, I've encountered -- I used to be part of the AI group that supported GM in the late 80s - early 90s. There it was always a feeling that: "If we can do it, it can't be AI."

In a recent article, Jack Vaughan quoted Jan Baan as saying, "The successor of ERP is BPM....ERP is becoming the model of complexity.  It has become too complicated."  Baan is CEO of Cordys and former head of Baan Corporation, an ERP vendor.  BPM (Business Process Management) is the leading edge of a major change in enterprise systems.

Much has changed since the heyday of ERP.  The Internet and internet technology has changed communications and integration.  Businesses are on-line and accessible from anywhere, any time.  The marketplace has become global for all enterprises, not just large companies.  The pace of change has accelerated, and information technology is pervasive in the operation of the enterprise and in society in general.  Business services are accessible, ad hoc, over the Internet, and service oriented architecture is changing not only the design of computer systems, but the design of enterprises.

ERP systems are traditionally monolithic solutions for automation of business operations.  They provide a solution for a particular way of doing business and typically require a major investment in implementation and adaptation to align the solution and the business operation.

The future requires enterprises, as well as systems, designed for change.   BPM, supported by business process management systems (BPMS) enables flexible automation of business processes.  ERP systems traditionally embed business processes in the code so that changes to business processes become IT projects.  A BPMS provides the opportunity to model and automate business processes in a way that is visible and adaptable by business people.  The BPMN 2.0 standard from OMG (Object Management Group) defines BPMS notation and modeling elements for defining and automating repeatable business processes. 

Not all business processes can be pre-defined and repeatable.  Some processes require ad hoc planning and decision-making by humans where actions are driven by the state of a case and records related to the case.  We characterize such processes as case management processes.  Some ERP systems provide record-keeping for case management.  Many other case management processes remain paper-based and manual because they don't fit the definable, repeatable model supported by most BPMSs.  OMG has initiated development of a Case Management Process Modeling (CMPM) standard for design and automation support for these processes, thus moving beyond the automation capabilities of ERP systems.

BPM, including case management, will improve the effectiveness and agility of business processes, but it does not necessarily improve the agility and overall efficiency of the enterprise.  Enterprise agility and efficiency involves changes to the design of the enterprise.  It requires the ability to rapidly adapt or create business capabilities and the ability to engage existing capabilities in new ways.  ERP systems are a barrier to such changes.  This agility is enabled by exposing business capabilities as sharable services.

In Business Capability Mapping: Staying Ahead of the Joneses, Denise Cook describes how business capabilities, at an appropriate level of granularity, represent stable components of the enterprise.  As services, these capabilities can be engaged by different business processes to meet the needs of different lines of business and adapt to changing business strategies.  These services must be loosely coupled so that they are independent of the individual lines of business to which they contribute or may contribute to in the future.  In Why SOA is a Business Necessity, I describe the importance of this service oriented architecture (SOA).

The identification and management of business capabilities as services requires a specialized discipline beyond conventional BPM.  This need is addressed by value chain modeling.  Value chain modeling was introduced by Michael Porter in 1985.  For more on value chain modeling and its various incarnations, see Value Chains and Other Processes, by Paul Harmon.  Value chain modeling brings a focus on the delivery of customer value and the capabilities that are required.  This analysis has been used at the executive level in strategic planning, but it typically lacks the detail to identify the stable units of capability that should be engaged as services.  This more detailed analysis as well as the design and management of shared services require a modeling environment to manage the complexity. 

This need will be addressed by a specification for value chain modeling being developed at OMG in response to the Value Delivery Metamodel RFP.  A value chain model will define the network of activities that contribute to the delivery of customer value.  These activities represent uses of business capabilities.  Different lines of business may have different value chains that define the uses, or potential uses, of shared capabilities. In addition to consolidation of capabilities for economies of scale and agility, this perspective supports consideration of investments in improvement as well as outsourcing and configuration of joint ventures.  Optimization will shift to an enterprise perspective, to reflect the cross-enterprise impact of shared capabilities that serve the needs of multiple lines of business.

This architecture is quite different from conventional ERP systems.  The business processes will no longer be embedded in program code.  The functionality that supports the stable business capabilities may be much the same, but it will be carved out to support loosely coupled services.  BPM is the beginning of the end for ERP systems as we know them.

We are in a state of transition to a new business paradigm.  The full transformation of enterprise systems and the enterprise will involve BPM, loose coupling of business capabilities and additional modeling capabilities that together will provide an enterprise architecture model from a business perspective.  Cordys and Hewlett-Packard are at the forefront of defining the business modeling specifications discussed above and the development of future enterprise architecture modeling capabilities.