Saturday, April 29, 2006

Enterprise Architecture v Services Federation Architecture

This post is based on a number of recent discussions (many of you will recognise some of the thoughts). It posits - A Service Federation approach would provide a better way of understanding, aligning and delivering business and IT services than that of traditional Enterprise Architecture.

‘Services Federation Architecture’ (SFA) is a simplified, more realistic and risk reducing approach to building IS systems. That is, realistic in the sense that the model provides a better representation of how the real-world actually operates.


Enterprise Architects usually approach their work top down– starting with business vision and strategy and working down to the implemented system components and the activities of the people that use them. This way of working has had a degree of success within the four walls of the organisation (in truth, however, rarely applied enterprise-wide). But more importantly, it breaks down across highly federated business scenarios like supply chains. Here multiple business domains interact around a common purpose and at the same time, operate within the context of their own business mission and behavioural traits. This world is less precision-engineered and more negotiated as events unfold – but within a simple model of well defined but relatively simple “touch-points”.

The need for a simplified approach services (from definition to delivery) is obvious in the highly federated world of international trading partners. For example, the joining up both human-based and technology-based services across an international supply chain involving different originations across multiple countries and many languages. Anything other than a simple model of the interfaces between interacting services would simply fail to be meaningful. Each of the members of this supply focused Value System ( “system” in the General Systems Theory abstract sense) operate both within the context of their own independent Value System and within that of the overarching supply chain.

Each constituent organisation is potentially both a consumer and provider of services (within the context of a particular business activity or task). However, despite the apparent complexity, these interacting services are naturally understood by the individuals involved and as is the notion of service governance through policies, contracts and SLAs between parties. The need to document the descriptions of the services provided and the associate information passed between each service (either verbal, paper-based or electronic) is also intuitive. There is a clear understanding of responsibility across the interacting domains and little desire to ‘peek into’ others processes as long as service levels are met or exceeded.

Contrast this with artefacts prescribed by many Enterprise Architecture frameworks. These frameworks focus on engineering rigour and traceability from the coarse-grained business strategies down to very fine-grained technology widgets. The architecture and engineering process wraps itself within its own language and with it, introduces multiple layers of translation between the originating business concept and the final operational outcome. This has the effect of dis-integrating IT away from the business and introduces delay and increases the risk of misinterpretation.

So what? - I believe we might be better off describing, creating and managing services using a “Service Provision in a Supply Chain” pattern rather than the “Construction Blueprint” or even, the slightly more applicable, “Town Planning” pattern. By doing this, perhaps, we can find a way to simplify how we conceive and deliver IT-enabled capabilities and at the same time, reconnect IT to the business.

There are many aspects to this discussion and as always, the interesting stuff is probably to be found somewhere between engineering rigour and operational pragmatics. I would like to explore this thinking here over the coming weeks. I also believe this is fundamental to the whole Services Fabric theme. While similar discussions have taken place in the past within the context of Object Orientation for example, I believe now is the right time to explore a more holistic, abstracted, macro approach to both business (e.g. trading-economies and global ecological needs) and IT (e.g. Web 2.0, Semantic Web, CEP.. et al). I feel this might drive out new insights and principles that can be applied at a macro level (e.g. pan-nation trade) right down to services delivered within an enterprise or by an individual - in all cases; without regard for the service delivery mechanism (e.g. IT-based or human-based).

Other related areas for discussion that come to mind:

  • Fractal Model (i.e. a model that is recursively constructed or self-similar, that is, like a shape that appears similar at all scales of magnification)
  • Value Networks and Domains of Control
  • Service Granularity: How to get in right – the Holy Grail!
  • A better representation of the real world and real-world-aware systems
  • Social networking and trading models
  • Multiple concurrent centres of gravity
  • The importance of understanding Events in a federated model.
  • Business and IT communication
  • The relative importance of re-use and of what?

5 comments:

Adrian Apthorp said...

Nigel,

If I take your definition of Enterprise Architecture as "traditional Enterprise Architecture" then I don't have much to argue about. However, isn't part of the issue the fact that Enterprise Architecture has been labelled an IT discipline, when of course it should be about the Enterprise?

If we refer to the Zachman Framework as the archetypal reference for Enterprise architecture once we delve below the second row we've focused on IT. This is not surprising when the original paper was titled, “A Framework for Information Systems Architecture”. Therefore if it were truly Enterprise wouldn't there be equivalent lower-level rows for other assets or resources of the Enterprise? At the end of the day an IT asset (application service?) is a participant in supporting the processes of the organisation.

Nigel Green said...

Adrian,
I agree, this has much to do with Enterprise Architecture being seen as an IT discipline. There are a number of discussions here and at the Capgemini CTO blog, that are all pointing to the need for a business-led 'Business Architecture' discipline - whatever its called!

Sally Bean said...

Adrian’s point is well made. John Zachman has now published a formal definition of the framework cells that allow the lower rows to describe all forms of technology, not just IT.
In the seminar held last year to launch these standards, a set of models for the London Underground were demonstrated, showing things like platforms, trains and tracks as row 4 and 5 constructs, whereas they would have previously been seen as row 2 and 3 constructs. However, I have to say that some of the audience were confused by this notion.

Adrian Apthorp said...

Sally, thanks for this. I wonder who the audience was? Each row needs of course to be viewed in the eyes of the stakeholder (owner, designer, etc).

In returning to my original comment I think that the same thing could be said about rows 1 and 2. In running an enterprise what is it that the owner and operator care about? For further insight, I think this is where Enterprise Architects need to look at the practices and models used by those responsible for supporting decisions at this level of the business; controlling / management accounting, change/ project portfolio management and business development. How do our concepts of Enterprise Architecture relate to the Balanced Scorecard or the project portfolio? What are their equivalents for the row 1 & 2 columns or cells of the Zachman Framework?

From recent experience I find it strange that business appears not to have a collective noun for describing the 'things' (data column) of the business. And then KPIs are measured in terms of them (e.g. number of active accounts, number of orders per month, product revenue). Of course when you introduce one it is interpreted as an IT concept...

Sally Bean said...

The audience were mainly enterprise architecture people with an information systems background.

This notion of other types of asset than information systems would be more familiar to military people for whom a system could be an information system, or something like a weapons system or a frigate.

John Zachman has addressed your point about collections of things, by renaming the cells in column 1 of the Framework (the WHAT column). These cells are now called Inventory, rather than Data.

As you point out, Data is only appropriate from Row 3 downwards, since Rows 1 and 2 are modelling the 'things' themselves, not how you represent them in a system.