The Next Big Leap: Everything is a Business Service

Since the 1970s, authors like Alvin Toffler[1], Daniel Bell[2] and John Naisbitt[3] have predicted the post-industrial society. They forecast the end of the industrial era and the dominance of services and information. This is not a new message[6]; the entire service provider industry has reformed around this idea, and in the USA today non-manufacturing industries account for almost 90 percent of the economy. Virtually every product today has a service component to it and many products have been transformed into services.

One of the most interesting examples of this is the Amazon Kindle service which provides an integrated front end to a wide range of Amazon services. The Kindle service optimizes purchases of books plus access to library and new services and automatically synchronizes all the devices the user may use to access the services including the Kindle reader, smart phone and browser.

Amazon was a pioneer in use of Web services. They are well known for their internal policy of mandating that all Amazon systems functionality should be created as externalized services – that is ready for use directly by customers, and this has clearly been at the heart of their considerable success.

However few large enterprises are able to operate in such an agile manner. Amazon was built from the ground up to be an IT enabled business. In larger enterprises generally there is weaker connection between business and IT, plus the challenges of legacy application and infrastructure base and typically immature (application) service portfolios. And we can all observe the archetypical enterprise is becoming even more complex with pressing demands to respond to major market trends including mobile device based processes, analytics and real time business intelligence driven process behaviour. In this frenetic environment, how can we avoid purely tactical responses which simply generate more complexity and legacy?

CBDI suggested the answer to this problem over ten years ago. The basic service model provides an efficient and effective architecture that enables reusable capabilities that limit complexity and enable continuous change through separation of concerns. However to be truly effective the service model needs to be integrated into the entire business ecosystem where EVERYTHING IS A BUSINESS SERVICE where, like Amazon, all business capabilities are published as integral components of product and service delivery. To achieve this, the service model must be expanded way beyond the prevailing technology centric SOA approach and become an holistic business service centric model subsuming PEOPLE, PROCESS AND TECHNOLOGY.

Of course there will be decoupling between business services and software services; it will be vital that business services are formed from reusable, common software services that can be rapidly assembled into new business processes to allow rapid response to changing business needs.

Of course this all sounds very fine, but most readers will ask the key question “how do we manage the transformation to a service based enterprise?”  There are so many cultural, political, budgetary and legacy challenges that will stop such an endeavour in its tracks. Most business managers have already dismissed SOA as a technical exercise and remain focused on delivery of urgent business programs. Frankly this is THE CHALLENGE. We all read fine statements from F500 CIOs and CEOs who boast about their transformations, but in practice business as usual perpetuates conventional separation of business and IT.  We have to communicate this from the rooftops!

Some ten years ago CBDI defined a maturity model and roadmap approach that showed how SOA capability maturity moves through the stages of Early Learning, Applied, Integration, Enterprise and Ecosystem. Since then this methodology has been used by many large corporations worldwide, including notably Intel Corp[4]. In the Ecosystem maturity stage the service portfolio is integrated with business concepts and federated both internally and externally. However few enterprises have achieved this level of maturity. Amazon is a rare exception.

Many enterprises are embracing Cloud computing recognizing this architecture can introduce a critical level of virtualization and agility. In recent months there has been much interest in moving Cloud to the next level referred to as Everything as a Service (EaaS or XaaS).  HP, just one of the service providers making moves in this space defines this as “Through the cloud, everything will be delivered as a service, from computing power to business processes to personal interactions[5].” This is a very significant advance, however we need to emphasize that Cloud EaaS is a technology centric model, and there’s considerable effort required to integrate with the broader business and IT to avoid yet more legacy.

 

A first step in making this level of transformation is to establish a reference architecture that is entirely service based, spanning business and IT. Frankly existing reference architecture efforts such as TOGAF, OASIS, Zachman etc are not helpful in this area. Rather the service reference architecture needs to provide a mapping to a multiplicity of (stakeholder) views identifying key elements of pattern, standard and policy to ensure appropriate levels of consistency and governance.

Each of the views should also be documented in reference architecture, enterprise architecture, solution architecture and analytics levels of abstraction. You may be wondering why analytics? This represents a further level of cross cutting solution abstraction.

As discussed the reference and enterprise architecture views should be developed to achieve the minimum necessary level of consistency relevant to the business strategy context. 

Everything is a Business Service is the next big leap. Enterprises who have established effective SOA environments will be well positioned to make this move, but recognize it’s going to be yet more steps along a much longer journey than we CBDI articulated in our research 15 years ago.

  [1] Future Shock

  [2] The Coming of Post-Industrial Society

  [3] Megatrends

  [4] Service Oriented Architecture Demystified, Intel Press 2007

  [5] http://www.hp.com/hpinfo/initiatives/eaas/index.html

[6] See for example Mapping the Enterprise - Modeling the Enterprise as Services 

African Sun Shines on the New Silos

I am sitting in the african sunshine supposedly having a month off work. However I suppose looking after grandchildren was never going to be a cakewalk! But one of the real benefits of taking time away, even if it's not a vacation as such, is that one gets time to sort out issues that have been bubbling away over time. The first is my PC configuration. Thank goodness, after just a few dedicated hours I will be much more efficient. The second one is documenting my thinking around architecture coordination in the delivery process.

I wrote a research report on this in April last year titled The New Silos [1] exploring the gaps between disciplines and suggesting a governance approach to establish cross discipline coordination. However my consulting experiences over the past 18 months have a) reinforced my opinion that this problem is pervasive and b) allowed me to refine my thinking and develop more robust solutions.

The issue that I come up against repeatedly is the inability of organizations to coordinate execution of of architecture, business strategy, business analysis and application delivery that optimizes the divisional and enterprise business outcomes. Examples of anti patterns I constantly observe include:
- business driven projects that select a major COTS product as pretty much the first action, that then drives business design and delivery in isolation of core enterprise goals (and creates a new silo).
- business users define requirements on the basis of changes to existing applications (that perpetuate existing silos)
- legacy applications are modernized by replacing existing systems with new technology without rearchitecting scope (that perpetuates existing silos)
- long project delivery timescales are addressed by concurrent release management (which increases product version and management complexity and cost, and generally fails to reduce overall functional delivery timescales)
- long project delivery timescales are addressed by agile development projects (without adequate enterprise architecture governance)
- frustration with all of above prompts business management to outsource arbitrary units of scope (which frequently creates new silos)
- frustration with all of above prompts business management to outsource to cloud provider (which frequently creates a new silo)
- enterprise architecture functions fail to show business value of broader perspective (and are bypassed by business and development)

The image below shows the coordination framework I draw to illustrate how we can address the above issues.










The framework infers (and requires) some really important policy changes:

1. Business strategy must be sufficiently understood to allow key questions of standardization, differentiation, capability independence and requirements for future agility to be applied to individual business problems
2. Enterprise architecture must link the business value of portfolio actions (from 1) with clear architecture direction.
3. Business requirements must be established as functional and non functional business models that are independent of applications
4. Demand management must break the linkage between business problems and delivery projects by consolidating similar requirements into clusters of services, components and solutions and determine opportunities to progressively rationalize the existing (legacy) portfolio
5. Programs or Projects must only be chartered once the problem is understood and the optimal service and solution architecture identified
6. The coordination activity itself requires governance to ensure stakeholder goals are met and to set governance criteria for delivery governance.

In my work over the last 18 months I have advised several very large organizations to establish a Design Authority (DA) as a key mechanism to manage the coordination. The DA should be made accountable for interpreting business priorities, transforming business requirements into delivery clusters of architecture work, services, processes and implementation components. The DA should be organized as cross functional, multi level (including exec level) and sufficiently empowered to make difficult decisions. Because, difficult decisions WILL arise. Stopping and restructuring critical business programs can be highly emotive, and the DA will need to be sufficiently strong enough to make recommendations that will be very difficult.

It constantly amazes me that most organizations don't yet operate in this manner. Of course culture, politics and career protection all militate against "radical". Yet in my experience, effective coordination of these critical perspectives will deliver real business value concurrent with dramatic reductions in complexity, cost and delivery times.

[1] Beware The New Silos! CBDI Journal April 2011