Dimensions of EA maturity

@gotze (John Gøtze) kindly sent me a copy of his 2010 paper Architecting the Firm (written with Pat Turner and Peter Bernus). My interest had been stimulated by Anders Jensen, who described the paper as follows in his blog on the Thinking Enterpri…

More on starting EA from scratch

A follow-on to the previous post ‘Where do we start with EA? – a practical question‘, to address a number of comments and questions that came up via the Twitterstream. Again, I’ll keep the emphasis on the ‘how-to’, and hold back on the theory this time. (Have a wander elsewhere through this blog for the […]

Let’s Kill the Confusion About Capabilities for Once and All!

I note in the Business Process Trends Advisor Paul Harmon is confused about what is a capability. What Harmon is missing is that capabilities are not just another modelling device that further helps to understand the business. Rather they are core structural concepts that allow us to establish independent units of capability. Capabilities are coarse grained business components that are inherently reusable. We define the characteristics as follows:

  • Service Oriented: Offers a software service.
  • Composite: May encapsulate all manner of behaviors including process, utility, core business (data) services.
  • Enduring: Outlives changes to how it is realized or the business processes that use it
  • Process Independent: May be used within several business processes
  • Implementation Independent: independent of how, where or by whom the capability is realized. Does not pre-empt or expose how each action is executed internally. Internal processes could therefore be changed and not impact the user of the capability service providing the contract remains unchanged.
  • Minimum Dependency: May depend upon another where a) it needs some other capability to have been exercised first or b) where there are internal dependencies. Some capabilities can be independent or self-contained. See below.
  • Measurable: Performance must be measurable

CBDI recommends:

  • whilst “not standalone” capabilities may be tactical necessities, standalone, fully independent capabilities are essential for maximum business agility, enabling replication, offshoring, ecosystem partner provisioning etc and reducing the horizon of change
  • also enabling maximum business agility, capabilities should offer a software service which is externalized, exposing the business capability to a wider world.

Harmon asks for examples. Look no further than Amazon – they offer well-formed capabilities that externalize the Amazon business such as Cloud Service; Storefront etc.

For more on this topic see the October CBDI Journal. It is free with simple registration.

Business Process Trends Advisor – Capabilities Again

Where do we start with EA? – a practical question

You’re an experienced enterprise-architect, having spent most your working life in one industry. You now have a new job, in a new company, in an industry that’s entirely new to you. And the company at present has no architecture at all: you’re ‘it’. Where on earth do you start? That’s the situation my friend Alan […]

How do we make EA make sense?

Those notions of ‘whole-enterprise architecture’ that I’ve been describing in the ‘no-plan Plan‘ series of posts make solid sense to a fair few people – particularly those who’ve some experience of systems-thinking, design-thinking and the like. But it’s painfully clear that it doesn’t seem to make much sense to anyone else: and I must admit […]

The Chief Process Office of an Agile Organization

The IDEF0 Pattern and the Organization’s Value EngineIn my book, Organizational Economics: the Formation of Wealth, I use the IDEF0 pattern to model the organization.  This pattern has three internal components, Control, Process, and Mechanisms (t…

The no-plan Plan: people in architecture

Okay, time for the final theme in that ‘no-plan Plan‘ – which somehow seems to be turning into a kind of ‘manifesto for whole-enterprise architecture’ or something like that, for some reason. Oh well. Anyway, this part’s about what is perhaps the most-serious ‘the Forgotten’ in almost all current ‘enterprise’-architectures, namely people. I’ll keep this one […]

The no-plan Plan: architecture-dynamics

And the next part of that expansion on my ‘no-plan Plan‘ (or ‘manifesto for whole-enterprise architecture’, or whatever it is): this time on the dynamics of architecture. In other words, it’s a focus on how we handle changes to the architecture itself, rather than mainly about changes that that architecture needs to address. Most of this […]

The no-plan Plan: architecture for change

And more on that expansion on my ‘no-plan Plan‘, which does seem to be morphing somewhat into a kind of ‘manifesto for whole-enterprise architecture’… Anyway, this part is about that theme of ‘architecture as change’ – though perhaps ‘architecture for change’ might be a better way to put it.. [Obviously this is related to the next […]

10 Key Success Factors for dealing with Enterprise Architecture

Secure the entire management commitment Secure scope(s) (partition) Customize methodologies to fit your intentions Use tools to support implementation Use training and coaching to secure knowledge and commitment is within specified limits. Use metrics to monitor the effects of Enterprise Architecture Create a set oriented fractal meta-model (yeah I know this sound weird) Use as few languages ​​as possible Manage materials, methods and resource Use […]

The no-plan Plan: the ‘why’ of architecture

A bit more detail on what I see coming up in my ‘no-plan Plan‘, starting with the theme about ‘the ‘why’ of architecture’. One thing I’ve always found worrying in most current ‘enterprise’-architecture is that there’s been almost no attention given to the ‘why’. It’s seemed that ‘why’ was just a given: ‘orders from above’, […]