Coordinating EA, SOA, Business Design, BPM, Business Capability Management and SOAM.
It’s a complicated world, and one of the primary ways we all cope with that is by specialization. For years I have characterized myself as a specialist in SOA; others will specialize in EA, BPM, PM, etc. But over the last year or two as SOA has moved into the mainstream we at CBDI have broadened the scope of our consulting, research and frameworks in both life cycle and discipline dimensions. The new scope includes practice support for standards such as ITIL, TOGAF, COBIT, eSCM and disciplines such as project management, transition management, BPM and testing, to name just a few. But it’s increasingly clear that the industry generally, as well as individual enterprises, is at risk of creating silos of the primary disciplines.
Many enterprises are now embracing the BPM discipline. After many years in the doldrums, the BPM market is unmistakably maturing rapidly. Acquisition of smaller, best of breed product suppliers by the major vendors must have been a primary contributor to increased activity, coupled with strong business pressures to rationalize and modernize business processes.
Similarly there is evident maturing of SOA. Again after many years of strategic commitment without effective governance, it is clear that SOA is now mainstream for many enterprises, a mandatory architecture pattern and technology for all projects and programs. We might discern two interrelated demand signals to:
1. deliver services from disparate back end systems to support BPM projects.
2. modernize application portfolios (rationalize, standardize, move to cloud) to reduce cost.
In practice these initiatives are frequently operating as silos with different sponsors, scopes, timescales and different objectives. To compound this there are other critical activities in EA and Business Design, which should be exerting governance and coordination but without due care and attention these may also be operating independently.
It’s not surprising these various silos can emerge almost by accident. The genesis of the disciplines is inward looking. Standards and frameworks have emerged that are primarily about each discipline. Of course, standards bodies typically compete not collaborate, and conflicting standards for the “same” discipline merely complicate the issue. Collaboration over inter-discipline standards is immature, and it’s common for standards some bodies to simply expand their efforts to cover new spaces without regard for clear separation of concerns.
A similar picture may be observed in many enterprises. In most organizations champions of a discipline emerge and there is healthy competition for mindshare, primarily of course with the status quo. The relative maturity of emerging disciplines will also be highly variable. It would not be uncommon for a single enterprise to have excellent experiences of mature and successful BPM projects with relatively immature SOA capability for common services and governance. And vice versa!
What’s required is a governance driven approach that provides just enough coordination to ensure the disciplines collaborate in an appropriate manner. In fact we recommend you should view the disciplines as components connected by services. Yes it’s an SOA! See image.
As the diagram illustrates there are three major tracks in play here – business architecture, business modernization and application modernization. Underlying all of these is SOA. In recent years there have been some attempts to recast EA as business architecture; but rightly these have been rejected because of the deeply entrenched IT perspective of archetypal EA. Rather what’s required is outline architectures for business and IT that can coordinate portfolio development and program management across the BPM and application domains.
Business modernization as the name implies is the transformation of business processes. Naturally these initiatives will span logical business components and domains. More worryingly they will look at slices of larger problem spaces, and so the need for coordination is paramount. BPM creates the demand for application and capability services and here each BPM project will frequently represent demand for a particular slice of a shared service. We recommend there should be a separate discipline for Business Capability Management which is equally as important as BPM. Consider a twin track (supply – demand pattern) operating between BPM and BCM in which BCM supplies cross cutting business capabilities that enforce enterprise standard behaviors and information.
The second important twin track is between Business Modernization (BCM plus BPM) and Service Oriented Application Modernization (SOAM). The SOAM discipline is tasked with meeting the BPM/BCM led demand, within the context of the EA, Business Architecture and SOA.
The SOAM needs to be agile and iterative implementing the service architecture on an evolving basis while progressively modernizing (rationalizing, componentizing) the application portfolio. But even more important, the SOAM needs to establish a capability to continuously evolve modernized application and service capabilities that can meet Business Design, BCM and BPM demand with the minimum cost and cycle time.
So it’s more complex than simply staging service delivery to meet BPM project demand. But I am not proposing an umbrella framework; rather I am recommending that disciplines are managed as components and offer and consume services from the other components. This approach will constrain scope creep in each discipline and allow specialists to work with defined dependencies with others.
In addition to services offered and consumed we should also place policy responsibility and authority upon each component. For example (at
the aggregate component level):
Business Architecture: standard business capabilities; standard business rules; standard business process behaviors; standard business semantics; shared service portfolio . . .
Business Modernization: business process ownership and design; business capability ownership and design; context specific service contracts; delivery priority . . .
SOAM: service contract design and ownership; component boundaries; supply contracts . . .
I will expand on these concepts, plus detail the services and policies for each of the disciplines in detail in an upcoming report to be published in the April CBDI Journal. You may subscribe at no charge here.