The Challenge

We probably can all agree that defining functional and non-functional requirements are the most critical elements of a project’s success or failure.  In fact searching Google for the simple search term “defining good requirements” returns over ninety-one (91) million hits! Yet in spite of all the good advice and fine writing available we have all seen inaccurate, incomplete, and poorly written requirements specifications. We all know this will result in poor quality products, wasted resources, higher costs, dissatisfied customers, and late project completion.  The cost to remediate these defects in development projects is staggering.  I’m going to try to keep this very professional and objective. I can’t help thinking this is probably a very good place to rant about the dismal state of affairs many of us find ourselves in today. We spend an enormous amount of energy to test executable code, yet the tests themselves are constructed on faulty assumptions or ambiguous specifications (you figure it out) that can’t be tested in the first place.  This is a common and all too familiar challenge I see everywhere in my practice. And I mean everywhere.

How bad is it?

More than 31% of all projects will be cancelled before completion. 53% of projects will take more time to complete and will cost twice as of their original estimates. Overall, the success rate for IT projects is less than 30%. Using generally accepted quantitative findings fixing requirements defects (errors) can eat up to roughly one third of most software project budgets. For example, requirements errors have been found to consume 28% to 42.5% of total software development cost (Hooks and Farry, 2001).  Rework can consume up to 40–50 percent of project budgets (Boehm and Basili). In fact, faulty requirements form the root cause for 75–85 percent of rework (Leffingwell). And early detection is critical. The cost to a 1 million dollar budget at the low end of scale can be more than $250,000. Finding and fixing defects outside the SDLC phase where it originates has its own cost (up to 400 times as much to remedy – Reifer, 2007).  It might cost $250 to $1000 to find and fix a requirements defect during the requirements phase. If uncovered when the product is in production repairing it can cost $100,000 to $400,000 in this example.  As Willie Sutton once said he robbed banks “because that’s where the money is”.   And so it is here where the real opportunity lies (and has been for some time) to capture and preserve real business value.  Reducing specification requirements errors is the single most effective action we can take to improve project outcomes.

The four biggest causes of failed projects are:

1. incomplete, missing, or poorly written requirements,
2. lack of user input and buy-in,
3. failure to define clear objectives, and
4. scope creep.

All four of these toot causes result from poor requirements and specifications practices. It is clear that current requirement management processes and tools are simply not working.

So what?

This is how we have always performed the work, why change the way we do this now? Crafting requirements specifications can seem like a daunting task. And how can the author tell the difference between a good requirement and a bad one? How can we ensure clear unambiguous system requirements are crafted on a consistent and repeatable basis? While many new business analysts are looking for templates it is rare a template provides enough rigor and information to help write better system requirements. Templates can help you get started, but they don’t really tell you what a good requirement looks like.  Understanding what represents good content in the requirement is a little more difficult (ex; Specific, Measurable, Achievable, Realistic, and Timely).  Even more difficult is preventing text ambiguity from occurring in the document(s) due to the presence of ‘non-actionable’, vague or imprecise language.

There is a better way

I have stumbled across a better way to tackle this challenge. The approach uses process improvements, a few new roles, and Natural Language Processing (NLP) technology to identify defects early in the development life cycle before they become expensive to correct.

The approach I propose is inexpensive and mitigates much of the risk associated with defects and errors early in the development life cycle.  We already have many fine tools to manage the traditional requirements practice. What I intend to share with you is very different and until very recently widely unknown to many in the development community.  The method works (IIBA’s Business Analysis Body of Knowledge) across all five types of requirements:

1. Business Requirements
2. Stakeholder Requirements
3. Functional Requirements
4. Nonfunctional Requirements, and
5.  Transition Requirements

The immediate benefit reduces costly rework (or downstream change requests) and the opportunity to build the right product the first time.  The more significant value is uncovering and reducing requirements defects early. This is the single most effective action (have I said this before?) we can take to improve our project outcomes. In the coming weeks I will address a method to tackle this challenge that is inexpensive and uncovers many of the defects and errors early in the development cycle.  I will share with you how to evaluate the following key elements:

• Structural Completeness/Alignment (%)
• Text Ambiguity and Context (Quality %)
• Section Quantity/Size
• Volatility (Change over time)
• Lexicon (Frequency Distribution across documents) Discovery
• Plain Language (Readability) Word Complexity Density – complex words

I will also illustrate how use Natural Language Processing (NLP) and text engineering tools to automate and identify defects. One of the most powerful features of this method is the immediate feedback provided to authors and designers early in the development life cycle.  They can then take action to correct the defects uncovered while they are still relatively inexpensive to remedy.  The end result is improved specifications to drive better products.  So if you are program manager, analyst, developer, or architect stay tuned for an approach that just may change the way you think about your writing. And improve your delivery of quality systems.

Tagged: Natural Language Processing, software system design, Systems Development

Are you concerned about the Elphaba’s in your business? Elphaba is more commonly known as the Wicked Witch of the West. Her business greeting is, “I’ll get you my pretty, and your little dog too!” She is green, ugly, and has a penchant for red shoes and fire. For all her

Did you know today is International Panic Day? An enterprise-wide technology failure is one of the biggest causes for panic in the business world behind maintaining profitability. If a company’s IT infrastructure or mission critical application goes down, it affects everyone – including customers.

Troux customer, Scottish Widows Investment Partnership (SWIP), a subsidiary of Lloyds Banking Group, supports over 500 financial professionals across a number of business teams including front office, compliance, risk and others. The company deploys cutting-edge technology to process huge volumes of data and manage sophisticated investment products, all within policies designed to meet industry and regulatory standards and policies. They can’t risk a possible technology failure.

SWIP sought out an enterprise portfolio management partner to evolve their solution architecturepractice and help the company scale. With aggressive growth plans on the horizon, changes had to be implemented quickly.

Luckily the EA team engaged Troux early, and using the Troux Accelerator methodology and EPM approach, SWIP was able to identify critical business questions that needed to be addressed in order to prevent future growth issues. Within just 12 weeks, SWIP was able to capture and store mission-critical information from six enterprise portfolios spanning business architecture, applications, goals and strategy, investments, technology and information.

As a result, SWIP was able to create SWIP Transformation Architecture Repository (STAR), a common platform that manages all elements of SWIP architecture, which allows the EA team to access data and information in real-time, across the company and the portfolios to easily scale to meet business needs.

STAR has become not just a tool for enterprise portfolio management, but a decision-making tool for stakeholders across the company. For example, in the event of a service failure, the IT support team can refer to STAR to identify the impacted applications, business functions and business capabilities. Reports producing all the information on a specific server can be run in seconds, providing enhanced information to support failure recovery and inform affected areas of the business.

So, if your company lacks the visibility needed to understand and deal with the potential of an enterprise-wide technology failure before it happens – don’t panic – Troux has you covered.

To read more about Scottish Widow Investment Portfolio’s experience with Troux, please visit: http://www.troux.com/outgoing/case_study_swip.pdf. To learn how your company can benefit from Enterprise Portfolio Management, please visit www.troux.com. 

I’ve been in a number of discussion recently that have made me think about ways to get projects off on a solid footing, understanding the real business context of a project.  I recently attended a course on requirements elicitation that made me think about useful techniques for “eliciting requirements” (whatever they are). Interestingly techniques such as SWOT analyses were not mentioned. I’ve had discussions with some of the business analysts at work about useful ways to capture what the context of a project is – in one case we made use of the VPEC-T method from Nigel Green’s book Lost in Translation. It therefore ironic that I later discussed this with Nigel himself when he posted a recent blog post on the topic of whatever happened to business analysis? In that post Nigel mentioned use of a range of tools including SWOT analysis, and it immediately got me thinking.

My suggestion is that at the start of a project you will find it really helpful (whether you are in the role of an architect, a business analyst or a project manager) to perform a SWOT analysis. In particular I’d recommend you run a SWOT analysis workshop with your key stakeholders both business and IT. A SWOT analysis will show you the Strengths and Weaknesses of your organisation (the internal positive and negative factors) , and it will show you the Opportunities and Threats for your organisation (external positive and negative factors) with respect to the project. This is vital information which will help your project succeed. I have been in many projects which have run into issues late in the life of the project and then someone turns around and says “but we all know that this is always a problem here…”. Key internal and external risks can be exposed, as well as opportunities that we can take advantage of. In any case, a significant part of the context of your project will be documented. Including both business and IT stakeholders in your analysis is crucial, as that is the only way you can get full coverage of the issues. The other useful fact about SWOT analyses is that they are a tool that many people in your business will understand. If your stakeholders are marketers or private sector senior management, this will be a language they understand, and you will therefore gain an opportunity to demonstrate that you can speak their language.

So next time you start a project, give it a try! The worst that can happen is you waste a few hours of time at the beginning of a project. The best that can happen is you can avoid wasting millions of dollars!

I find from our - very limited - experience that we wound up with a distribution of investments that’s roughly equivalent to population demographics.   Our deal flow pipeline is also distributed by gender and race along the lines of general population statistics.  It’s nowhere near to being a statistically significant representative sample, but it’s odd that our results are so different from what other folks are reporting.

Bottom Line:  Opinions here are welcome.

It’s been over 5 years since Carl and I stumbled upon VPEC-T thinking, whilst working with the UK’s Criminal Justice organisation. We’ve both enjoyed numerous conversations with people who tell us that they’ve found it useful,  in a wide range of circumstances.   I’m interested, however,  in hearing more about how VPEC-T has been applied,  and in sharing these scenarios publicly, so that others might find their own way to apply the framework. I’m particularly interested in the circumstances which led to its use, the method used to start the VPEC-T conversation, other models/canvasses that helped frame the conversation, insights that emerged and, last but not least, what worked and, more importantly to me, what didn’t.  Feedback on the use/usefulness of VPEC-T has always been difficult: the nature of a framework that examines sensitive issues, like Values and Trust, becomes a barrier to public feedback. In the spirit, however,  of openness and sharing, but recognising such sensitivities,  I’m not asking anyone to disclose specifics, instead, Im asking for more general,  anonymised, observations. 

1. What were the general circumstances that led to a VPEC-T analysis?
2. How did you bound the conversation – did you use a model or canvas to help focus-in?
3. How did you conduct the VPEC-T analysis – a workshop (how many participants?), 1-on-1, or other?
4. Which dimension (i.e. V-P-E-C-T) did you start with and which dimension(s) stimulated the most insights? 
5. What were the main barriers to getting the conversation going or issues that became a stumbling-block? How did you overcome?
6. What was the nature of the output/insights from the session and where/how did VPEC-T add the most value in surfacing them?

Not surprisingly, I’ve used VPEC-T in many different scenarios, sometimes explicitly, and sometimes  as a, non-disclosed, mental model, for analysing  at a problem or opportunity.  The most valuable feedback to me, however, has always come from others – their unimagined (by me!) challenges and circumstances. Ever since my original blog post in 2007, I’ve been keen to share and develop the thinking publicly (despite pressures to do otherwise!). Can I encourage others to do the same?  I guess I’ll see.  Any better ideas on soliciting feedback always welcome! (thought to self: I wonder if I could find a way to use Dave Snowden’s Sensemaker tool?).

To me at least, these were the key aims for a brief one-day mini-conference on ‘EA and Systems Thinking’ last week in London, organised by Richard Veryard, Sally Bean and Jiri Ludvik.

We’d hoped to Tweet the conference itself on the hashtag #EASTmeeting, but unfortunately there was no wi-fi available in the conference-space. Hence, no Tweets – apologies! As possible compensation, though, what follows here are various assorted bits-and-pieces from my notes of the day: I hope you find them useful?

The day started off with an intro by Richard Veryard and Sally Bean. One of the themes here was that, for any kind of whole-of-systems approach, we need to link up with the people who make whole-of-context decisions. But as Richard illustrated with an example of trying to address core issues in the UK National Health Service, getting to the people who actually make those decisions is really hard, if not all-but-impossible. (Myself, I’m beginning to wonder if there is anyone who makes such decisions – and the absence of which is probably a key reason why things are in such a mess…)

Looking at EA (enterprise-architecture) and ST (systems-thinking), we use the term ‘we’ to describe the respective practitioners – yet who is ‘We’? There don’t seem to be any clear distinctions, any absolute boundaries that determine who’s ‘in’ and who’s ‘out’ – all a bit blurry all round, really. Part of it is that neither EA nor systems-thinking represent an explicit profession in their own right as yet: more just a variously-blurry set of clusters of disciplines and practices, perhaps more characteristic of a shared-enterprise than anything else.

One of the few things that is evident – all too evident, often – is a strange passion for spurious certainties, ardent assertions of absolute ‘truths’ where, almost by definition, it’s probable no such ‘truths’ are to be had. Over in systems-thinking, there are endless fights between hard-systems theorists and soft-systems theorists, VSMers versus value-streamers, the Seddonites against just about everyone else; here in EA, of course, there are the TOGAFites, DODAFites and FEAFites, those who insist that it’s always and only about IT, and those who equally-vehemently insist that it isn”t. One of themes that almost all systems-thinking practitioners preach is that we need to create systems and structures that can tolerate high levels of ambiguity, uncertainty and difference – but we’re often oddly abysmal at doing so ourselves. Oops…

On the human side of EA and systems-thinking, Sally Bean commented on a cross-over to the kind of space more usually occupied by knowledge-management. To me, that’s definitely true; and there’s also a similar cross-over with futures and strategy. None of that should be surprising, given that we purport to cover the whole context-space: yet perhaps those other disciplines might provide us with useful examples and allies?

At this point Steve Brewis of British Telecom took over, with a presentation on how he’d applied systems-thinking techniques – particularly Viable System Model – in building tools to help manage the huge complexities of the telecom’s physical, technical and human networks, and to tackle complex issues such as the ways in which changing energy-prices affect the choices and viability of the whole network.

Some quick themes:

• naming alone is not enough, we need meaning – a shift from taxonomy to ontology
• value is a systemic construct – it’s not intrinsic, it arises from the overall network itself
• chunking makes things more ‘manageable’, but destroys connections that create value

And a ‘capability and capacity maturity-model’:

1. Capability
2. Connected to business-commitment [? - can't read my own scrawl there...]
3. Balance
4. Conscious / awareness (essential for feedback-loops)
5. Conscience – ‘right things for right reasons’

Steve introduced a key concept of ferality, ‘going feral’, “an auto-catalytic phenomenon that is self-perpetuating’ – such as trying to ‘control’ by putting more managers in… Key causes of ferality include:

• ignorance
• specialisation
• partitioning
• too much emphasis on (local) difference
• no account taken of agile behaviour or agile needs
• does not consider / acknowledge / respect system-wide decisions or business-rules

Specialisation, for example, creates spurious (local) ‘efficiency’, without awareness of impacts on (global) effectiveness. Often there’s no sense of awareness of who (if anyone) is responsible for coordination (in other words, for absorbing coordination-complexity).

Steve argued that business-rules bring the system alive, by providing the motivating ‘Why’, rather than the more usual demotivating ‘Why you should not’. (I’m not sure I agree with Steve on this: in my experience, I’ve more often seen the presence – rather than absence – of predefined ‘business-rules’ to be the root-cause of problems, rather than their solution. Rather than fixed ‘business-rules’ [SCAN: Simple], we often need more fluid, contextually-adaptable principles [SCAN: Not-known].)

Peer-to-peer conversation is crucial (in effect, providing VSM’s system-2 coordination and system-3* audit services). Also “We understand services through the eyes of the customer”: this is very different from a factory context – Taylorism doesn’t work for services.

Steve demonstrated a live simulation ‘dashboard’ he’d developed for managers and others at BT, showing the whole business-context somewhat in VSM terms. (I’ll have to admit that the maths and IT-systems-knowledge involved in this was way out of my league…) ”It’s always useful to compare against the same time last year”, he said, “to see how we’re performing to seasonal demand”. (I have my doubts here: doesn’t this assume linearity of demand from year to year? What about the realities of variety-weather? Is there a risk here that this could become a kind of VSM-lite, mis-applied to prop up the myth of ‘control’ for managers?)

The purpose of the mathematical model, he said, is to enable to business to respond to customer demand. “Service – non-predictable, high-variety – is different from a factory -where variety can be ‘controlled’. VSM gives us ‘centralised decentralisation’.” (It’s ‘more understandable’, yes – but at the cost of loss of visibility of real complexity?)

And finally, a couple of replies to questions, first on his own relationship with EA in the organisation: “EA in BT are focussed solely on IT – I’m not. The IT-people have co-opted EA…”. And also “Ontologies are dynamic, not static” – they change over time, in response to business context and business need.

After a useful small-group discussion – the conference-schedule allowed plenty of time for these, which was good – next up was John Holland, on why EA is broken, and how ST can help.

I didn’t take anything like enough notes here – sorry! But the core, I’d guess, was really just a catalogue of the various ways in which mainstream ‘EA’ is broken: it’s literally static, in the sense of ‘state-oriented’; it takes too long; it doesn’t match up with reality; and so on, and so on, and so on. Painfully familiar for anyone who’s been around in ‘the trade’ for any length of time and whose work touches anything outside of IT, of course, but often far from obvious for anyone else. His real question – or challenge to the group, rather – was “How can we use ST to do stuff better?” – or better than the limiting mess of IT-centric ‘EA’, anyway.

Quite a lot of discussion ensued in our various small-groups. Sally Bean‘s group focussed on the centrality of requirements in TOGAF, pointing to Steven Spewak’s work: “there is no such thing as requirements”. “We’re moving away from requirements – moving towards success-stories or outcomes - because it identifies [future] value.” Someone else commented that although functional-specification requirements are limited, or worse, there are other kinds of ‘requirements’ that are useful, such as:

• outcome-requirements
• “a day in the life of…” requirements
• “we’d like to explore this…” R&D-requirements

Another comment from one of the other groups was that “the TOGAFites are not the whole of EA, just as the Seddonites are not the whole of ST”.

And a final comment in that section – from Steve Brewis, I think? – was that the key business-benefit of combining EA and ST was to improve ‘decidability and manageability’. Not sure I’d fully agree – especially around ‘manageability’, which risks taking us back to Taylorist territory all over again – but yes, important themes, at the least.

Next Richard Veryard, with more on links between EA and ST, and the overall complexities of the business-context. Usefully, Richard also described a key challenge illustrated by ‘the Warning of the Doorknob’: the tendency for systems-thinkers to get caught in ever-extending escalation towards ‘big-picture’ – the inverse of the analysts’ tendency toward ever-finer-detail regression and decomposition. In other words, exactly as we need to be careful to constrain ourselves to Just Enough Detail, we need Just Enough Big-Picture too.

The common challenge for both EA and ST, Richard suggested, is to create interoperability between all the different viewpoints and (time)scales. And in that I would definitely concur.

Which lead us to the final main session, by Patrick Hoverstadt and Lucy Loh, presenting a kind of comparison between the worldviews, tools and techniques of EA and ST, and how we could bring them closer together – based on a study that they’d conducted for and with the original EAST group.

It was a good session, and in its way a good study, but I’d have to admit that that I found myself bouncing back and forth between mildly-grudging agreement and near-apoplectic fury. The reason for the former was that whilst Patrick definitely knows his stuff – see his book The Fractal Organization - he tends to focus on VSM almost to the exclusion of everything else; and the reason for the latter was that, all the way through, his effective definition of ‘EA’ was little more than TOGAF-style IT-centrism – which made the whole analysis seem way too much like a crude ‘strawman argument‘ against all forms of EA. (I know there were several others there who felt that way, too.) Just as one illustration here, Patrick listed VSM as a technique used solely in systems-thinking and not in EA, whereas I’ve been using it as a core theme in much of my EA work for many years now – for example, it’s a key component in service-modelling with Enterprise Canvas. Part of my over-reaction to this is probably the usual ‘curse of knowledge’, of course: I’d have to admit that my own EA practice is quite a long way out on the bell-curve, and it’s true that many existing ‘EA’-practitioners would be comfortable enough with the more myopic subset of ‘real-EA’ that Patrick described. The whole point of the conference, though, was to find ways to break EA out of that IT-centric box: yet here was Patrick firmly pushing us back into it again – and the fact rankled. A lot. Which kinda distracted. Oh well.

(Perhaps the simplest way to summarise it is that, to use James Lapalme’s ‘Three Schools of Enterprise Architecture‘, Patrick and Lucy’s study was based firmly on ‘first school’ – ‘Enterprise-Wide IT-Platform’ – whereas it’s probable that most if not all of the EA practitioners at the conference would have been ‘third school’ – ‘Enterprise-In-Environment’. Hence the clash of perspectives: Patrick and Lucy were describing a view of EA that the practitioners there had, through much hard work, largely left behind – and did not want to be dragged back to it again!)

One useful part of their study, though, was the use of an ‘organisational model’ (which I would probably term more as a capability-model) to act as a conceptual ‘spine’ against which all the other disparate models can connect.

Also, importantly – and I agree with them on this – neither the mainstream ‘EA’ toolset, nor the various ‘ST’ toolsets are complete enough on their own: we need to merge them together to create a true whole-of-enterprise toolkit.

And Patrick (or maybe someone else – I didn’t note it down) ended with the rhetorical question “Is the ‘architecture’ metaphor still helpful here?” To which the general consensus was ‘Probably not’ – but as yet we don’t have a clear alternative with which to replace it. Which is a very real problem we still all face at present. Hmm…

Overall, a good day: well worth doing, at any rate. (There’s some real hope that it’ll happen again in the relatively near future – perhaps in other cities elsewhere.)

The only catch, for me, is that it still doesn’t satisfy what to me is the driving need, for both EA and ST: to bring it down from the airy abstractions, and reframe it in more tangible and practical form. But it’s enough of a start for now, I guess: one step at a time, one step at a time…

Over to you for comments, perhaps?

A business can be anything from a single person operation through to a multinational conglomerate or a government. All have missions that define their goals and objectives. All have internal and external driver that affects what they do..All wish to succeed in their endeavours.

The one person business, in establishing their initial business plan must, if they wish to succeed, define what it is they wish to achieve and decide if it is actually ‘doable’.

• Understanding what capabilities they have and what additional ones are required to deliver on its mission helps in shaping the business plan.
• Defining the measures of success and having a view as to when success should be achieved allows them to monitor progress.
• Describing the processes they will use, the costs of implementing each and how they inter-relate enables the possibility of business process improvement.

How does this differ from what is required of the multi-national or government.

The ‘larger’ the business the greater its inherent complexity yet the impact, on getting it wrong, can be seemingly just as great for the small business as for the large. Not succeeding for the small business can mean it closes. Not succeeding for the large may not be as terminal.

Good, well informed decisions, made in the very small through to the ultra large enterprises are crucial for realising their individual success.

This can only occur if they have access to a repository of knowledge and information from which to draw.

An Enterprise Architecture or something which is equivalent (the name is irrelevant) can provide the information that is required to support decisions that will provide an optimal path to success. Where it does not exist the enterprise should look at establishing one or risk failing to achieve what it wants.

An Enterprise Architecture is able to contribute significant value no matter the size or the nature of the business.

A business can be anything from a single person operation through to a multinational conglomerate or a government. All have missions that define their goals and objectives. All wish to succeed in their endeavours.

The one person business, in establishing their initial business plan must, if they wish to succeed, define what it is they wish to achieve and decide if it is actually ‘doable’.

• Understanding what capabilities they have and what additional ones are required to deliver on its mission helps in shaping the business plan.
• Defining the measures of success and having a view as to when success should be achieved allows them to monitor progress.
• Describing the processes they will use, the costs of implementing each and how they inter-relate enables the possibility of business process improvement.

How does this differ from what is required of the multi-national or government.

The ‘larger’ the business the greater its inherent complexity yet the impact, on getting it wrong, can be seemingly just as great for the small business as for the large. Not succeeding for the small business can mean it closes. Not succeeding for the large may not be as terminal.

Good, well informed decisions, made in the very small through to the ultra large enterprises are crucial for realising their individual success.

This can only occur if they have a repository of information from which to draw.

An Enterprise Architecture or something which is equivalent (the name is irrelevant) can provide the information that is required to support decisions that will provide an optimal path to success. Where it does not exist the enterprise should look at establishing one or risk failing to achieve what it wants.

What are Business Capabilities?

A Business Capability represents the ability of an organisation to perform an activity that results in an outcome of value. Business Capabilities are as far as possible expressed in terms of those business outcomes and value. As far as I know the concept originated from MODAF and was later adopted by TOGAF. See http://en.wikipedia.org/wiki/Capability_management_in_business

Many Enterprise Architects and organisations fail to really use them, but in fact they are slowly becoming a common EA deliverable and a way of developing a target operating model view.

The key to their increasing popularity is because the Business Capabilities are expressed in terms of business outcomes and value rather than in purely functional or IT terms (i.e. Not just in terms of business unit needs or in terms of IT Solutions) thereby ensuring IT alignment with the business. Being expressed in terms of outcomes and values also means that Business Capabilities are tied to the outside in perspective of the Customer Journey and Strategic Scenarios, rather than the inside out perspective.

A good book to read about the outside in perspective is “Outside In: The power of putting Customers at the Center of Your business” by Harley Manning et al. http://www.amazon.co.uk/Outside-In-Putting-Customers-Business/dp/1477800085/ref=sr_1_1?ie=UTF8&qid=1371351364&sr=8-1&keywords=outside+in.

In order for an organisation to perform an activity, many parts of the organisation need to be involved. Consequently a Business Capability is modelled as grouping of other EA concepts including the following:

• People
• Organisation Units
• Functions
• Processes
• Business Services
• Information & Data
• Application Services
• Applications
• Infrastructure Services
• Infrastructure

In this way a Business Capability can be seen as a cross cutting slice through a typical enterprise architecture model.

A Business Capability is used for managing units of strategic business change and providing the mandate for programmes and project portfolio. Subsequently, project will develop a solution that either creates a whole new Business Capability or updates a Business capability by implementing a Capability Increment.

Thus, Business Capabilities and Capability increments provide the basis for the development of the EA Roadmap.

Business Capability Model

Figure 1: Example Business Capability Model Source: UK Government Reference Architecture (UKRA) v1.0

This diagram illustrates the start point for a Business Capability Model. This is a static view based on the style of IBM’s Component Business Model. This is a style diagram that has become quite popular.

The whole matrix represents all the Business Capabilities that the organisation performs. Each cell is a Business Capability.

The Columns usually reflect the high level value chain for the organisation or are major groupings of Business Capabilities that are meaningful to the business.

The Rows reflect the fundamental purpose of a Business Capability and there are normally three rows:

For details about VSM, the Viable system Model see http://en.wikipedia.org/wiki/Viable_System_Model and my earlier blog posts.

Business Capabilities also have dependencies between them. I.e. one Business Capability has to exist before another Business Capability can be achieved.

Implementing Business Strategies requires new or changed Business Capabilities, but for the most cases we are just changing some aspects of the Business Capability rather than introducing brand new ones. This is the Capability Increment.

Relationship between Business Capabilities, Enterprise Architecture and projects

Figure 2: Diagram showing Business Capabilities Source: TOGAF

The diagram above shows the relationships between Business Capabilities and Capability Increments, and also related the Enterprise Architecture development method phases and definition of work packages for the Programme and Project Portfolios.

Capability Increments document the changes to each Business Capability that are needed to implement the Business or IT Strategies.

Each Business Capability is decomposed into one or more Capability Increments that are typically implemented at different points in time and in different Transition Architectures. Each Capability Increment represents a unit of change.

Capability Increments also have dependencies between them. I.e. one Capability Increment has to be implemented before another Capability Increment can be achieved.

Figure 3: Capability Dependency Model

The diagram above shows the dependency relationships between the Business Capabilities and between the Capability Increments.

The Capability Increments can be rearranged to show the dependency order in which they need to be applied. This sequence forms the basis for the EA Roadmap.

Figure 4: EA Roadmap structure

Often it is may be useful (and politic) to represent several tracks in the EA Roadmap. For example tracks may be introduced for Strategic changes, Business changes and IT changes, since Capability increments may be identified in such a way that they can be implemented in parallel.

The Capability Increments can be grouped into Transition Architectures. A Transition Architecture is an intermediate Architecture model somewhere between the current state and the future (target) state Enterprise Architecture model being aimed for. A Transition Architecture will typically be aligned to intermediate and temporary stages in implementation.

Groups of one or more Capability Increments will provide the mandate for a solution or service to be developed in a project.

A Business Capability Model should be at the core of all Enterprise Architecture Models.

Often the Architecture Vision Model or Core Model is produced as a Business Capability Model to provide a strategic view that helps all stakeholders in an organisation to develop a common understanding of what needs to be done and what needs to be changed.

(With thanks to Lee Hepplewhite for some aspects of this approach)

Filed under: Business Transformation, EA Roadmap, Enterprise Architecture, Enterprise Processes Tagged: Business Capability Model, EA Roadmap, Enterprise Architecture

This is described as an Aggregated Enterprise Architecture Wisdom and I have found it to be a good collection of articles and recommend it to all Enterprise Architects out there.

Filed under: Blogroll, EA Magazines, Enterprise Architecture

Enterprise Architecture is essentially a strategic planning discipline for ensuring that all the strategies of an enterprise are well executed. How should we measure it and how it is performing?

First it’s best to clearly understand what Enterprise Architecture is and who it is for.

Enterprise Architecture bridges the gap between those decision makers who come up with new strategies and objectives and those who are involved in enterprise transformation and investments in change. It is about what the enterprise can do now (baseline capabilities) and what it wants to be able to do in the future (target capabilities).

Enterprise Architecture is all about keeping an organisation robust, viable and continuing to satisfy all its stakeholders in the future, who are interested in the enterprise succeeding and continuing to succeed i.e. the CxOs, Shareholders, Customers, Partners, Suppliers etc.

The Enterprise Architecture deliverables are a conceptual blueprint or Target Operating Model that explicitly defines the mission, vision, strategies, objectives, principles, standards and business capabilities at the strategic level, as well as all the other elements (component types) in the enterprise that define how the business operates. These elements include business functions, business services, business processes, scenarios, value chains, value streams, products, application services, applications, technology and infrastructure and are defined within the following Architecture domains:

Enterprise Architecture also provides several different views of how an enterprise operates and changes, by maintaining a baseline enterprise (operating) model, target enterprise (operating) model(s) and a roadmap of changes to the enterprise’s business capabilities and investments in change ordered within an enterprise transformation roadmap.

Measures and metrics

A large number of organizations use Enterprise Architecture approach in order to plan strategic changes and manage enterprise transformations. Enterprise Architecture is not directly linked to a direct outcome but is usually indirectly related.

One of the major concerns is the failure of many enterprises to actually measure the value of their current or baseline Enterprise Architecture. One is reminded of the old adage ‘What you don’t measure, you can’t manage’. When changes occur as a result of new strategies and target enterprise models, the subsequent enterprise transformation may well be many months or years into the future. Changes are delivered by other groups inside the enterprise or external solution delivery partners. If measures and metrics are not used and actively managed then it becomes rather difficult to compare the old baseline with the new baseline to see what value has been achieved.

Identify the Metrics

The measuring metrics will vary from one enterprise to another. As Enterprise Architecture exists to support the CxOs and decision makers within the enterprise then it is important to define the metrics from their perspective.

Metrics can be identified form a number of perspectives.

Broadly these can be grouped into:

More detailed metrics can defined for each Architecture Domain. Here below is a discussion of some of some potential metrics used for measurement of their enterprise architecture’s value.

CxO’s Metrics

The Enterprise Architecture is by definition the architecture of the enterprise, so the metrics also need to be defined from the enterprise or business perspective. The CEO and other CxOs are responsible for managing the enterprise so the metrics need to be ones that they are interested in and keen to measure. These may include:

• Completed transactions
• Revenues
• Operating expenses
• Profit
• Revenue per dollar of operating cost
• Profit per completed transaction
• Productivity
• Profits per investment

The trends and rates of change in the numbers are often more important than the actual numbers.

If the enterprise strategies and therefore the target Enterprise Architecture are not having an effect (directly or indirectly) on the numbers that the CEO is interested in, then the Enterprise Architecture is not being effective.

Customer experience metrics

One of the biggest contributions to Enterprise success and profits is the overall customer experience and satisfaction. There are three categories of Customer experience metrics:

These metrics measures how happy a customer or prospective customer is with the enterprise’s value proposition (their products and business services). What value is provided to the customer? This measure is becoming common with value based pricing approaches. How easy is it for the customers to do business with you? Do the enterprise business services provide for the needs of the customer’s own internal processes? Customer Satisfaction can be increased by better communication with them through their preferred channel, so a measure of Customer communications (messages and interactions, social media) can be useful.

Cost Benefit

Cost/Benefit ratio to measure the value of any new or changed business capability. This is used to compares the amount of money spent on the transformation (costs) to the amount of money that is being saved after the implementation of the changes (Benefits). These metrics are often measured in terms of money, but in fact the benefits may be non-monetary values such as increased sales, improved customer satisfaction, reduction of risks, increased flexibility, and improved platform for future change.

Productivity and Effectiveness

CEOs will be concerned with the effects of Enterprise Architecture and new investments on production, efficiency and effectiveness. Metrics in this area can focus on:

• Reducing time to market for new investments in change
• Integrating and improving business processes across the enterprise (including with partners)
• Improving the ability to integrate data and interfaces across the enterprise (including with external partners)
• Improving the ability to reuse business functions, business processes and application services
• Increasing agility, flexibility and ability to rapidly change in the event of new strategic scenarios occurring
• Increasing standardization
• Reducing the time taken to develop solutions by maximizing reuse of enterprise architecture models

Governance and compliance

Enterprise Architecture ensures that the strategies of the enterprise are realised.

How many business capabilities are being created, updated or removed? What capability increments are being turned into investment proposals and providing the mandates for new programmes and projects? How many capability increments are being delivered by the solutions that have been subsequently designed and developed? How well are the solutions in compliance with the target enterprise architecture model?

Knowledge

The Enterprise Architecture function will create a well-populated repository of knowledge about the current state of an enterprise and its planned future state vision. The enterprise Architecture models provide a knowledge base for CEOs, CxOs and other decision makers that provides answers to their questions. In essence an enterprise architecture model needs to be designed to answer all their potential questions. How well does it achieve that?

These questions can be about gaps, impacts, dependencies, probabilities of success and failure, risks, costs etc. One of the major concerns of Enterprise Architecture is to reuse the knowledge, information and data as required by various processes and applications throughout the enterprise. Metrics can include the percentage completeness of this knowledge base. How easily and readily available is this knowledge throughout the enterprise to those stakeholders who need it?

A Common Vision of the future state

The whole purpose of Enterprise Architecture is to align investments in change with the strategies for the future of the enterprise. The target Enterprise Architecture Model is the target operating model that provides a common vision for all parts of the enterprise, including internal business units and external partners. How complete is this model and all the associated diagrams and documentation? Is it readily available?

Enterprise Transformation

The target enterprise architecture model will reduce the time it takes to conduct a particular enterprise transformation, implement new and changed business capabilities and reduce solution design and delivery time and development costs by maximising reuse of the enterprise level models. It will provide standard components and ensure maximum reuse of them across the whole enterprise. Over time the enterprise architecture will ensure faster development, fewer failures and better alignment to strategic enterprise level requirements and continual improvement.

Qualities

The Enterprise Architecture is often focused on improving or enabling various characteristics and qualities in the future.

Metrics can be based on these qualities can include:

• Efficiency
• Robustness
• Reliability
• Viability (ability to remain viable in a changed environment)
• Flexibility (ability to automatically adapt when unexpected external changes occur)
• Complexity
• Agility (Ability to adapt to changing business needs)
• Adaptability
• Ease of integration
• Amount of reuse
• Support for innovation
• Service level
• Quality
• Accuracy

In conclusion

Enterprises need to measure Enterprise Architecture by how well it improves the performance of the whole enterprise, meets its business needs, and supports its strategies and investments in change.

Filed under: Enterprise Architecture, Performance Architecture, Value of EA