Processes and capabilities

My opinions on processes and capabilities have changed.  That doesn’t sound like a sesmic shift, does it ?  That sounds like I’d been considering it and I’d changed my views based on new evidence.  People are allowed to change their mind, aren’t they ?  But that’s not how this felt; this felt like a fundamental realignment, like the sun started to go around the moon or mice started to chase the cat.  I’d been talking to people about capability models for years, eschewing process models and I suddenly found capability models to be just a tool, not the answer that I’d always thought that they were.  So how did this come about ……….. ?

I was challenged recently to build a process architecture, from scratch, for an existing organisation and to make use of a team of business analysts to capture the more detailed processes.  I quickly sketched both a level 0 process model and a level 0 capability model and it was immediately clear that only the process model described what the organisation did and was useful for the business analysts.  We used the business model canvas as a level 0 process model.  I should have drawn a rich picture, framed for posterity, but laughter in the room curtailed my early attempts at art.  The canvas clearly showed the organisation did; it was immediately understandable and comprehensive.  We then moved on to level 1 – a set of value streams, ala Porter.  Level 2, the first ‘real’ processes, were the steps necessary in each value chain and I left the business analysts to define levels 3-5, while I started the operating model.

So what’s the use for a capability model ?  The answer to that become clear as I reviewed the level 4 processes some time later.  The processes were mis-leveled, but that’s to be expected.  What I hadn’t counted on was the ingenuity of those interviewed to capture the business processes.  They’d managed to make very similar process steps sound completely different between divisions: the levels were different, the steps were different and the nomenclature was different.  Whilst removing the dichotemy was one of the reasons that we’d got the job, I was stuck.  I couldn’t change the processes but I needed to demonstrate the similarities bewteen them.  What I needed was an independant framework that I could use to demonstrate that the processes were similar across divisions.

So we mapped each process step to a (set of) capabilities.  I’d used the capability model in the TM Forum eTom Frameworx as a start-point and that was useful to demonstrate to the business analysts what the difference was between a capability and a process.  Once we’d reviewed the capabilities necessary to deliver each process step, we were ready to ‘discuss’ them with the process leads and explain the similarities in their processes.  Showing the process leads that the capabilities necesssary to deliver the processes were identical allowed them to see that the processes should be similar too.  Objective achieved !

But what of the capability model ?  Is it just a tool to clarify processes ?  Well yes: in this case, it was.  However, if I’d been asked at the outset to define the capabilities that the organisation offered, I would have started with level 1 being a capability map and the decomposition would have uncovered which processes delivered which capability.

So, in summary, it’s not necessary to chose between processes and capabilities: pick the approach that delivers the right output.  In this case, in the age of the ‘digital organisation’ I was probably asked the wrong question: I should have been asked to define the capabilities that the organisation offers to market, not look inward at the processes and ignore the customers.

Relating IT and Enterprise Architecture

IT Architects have a hard time.  It’s commonly perceived that the IT department is slow to deliver the whole solution, can’t keep up with the business and is too expensive.  In any solution discussion, there always seem to be a lot of IT architects, each espousing a different technology as the ‘silver bullet’ and often disagreeing with each other to the point of religious fervour.  Passionate yes, and misguided – maybe.

Those IT department traits, I believe, are symptoms of the stage at which IT Architects are included in any business discussion, but I’m not advocating bringing them in earlier either !  In the recent conversations about whether CIOs should be given a seat on the board, my position was that they should and deservedly so.  What I got wrong was what would happen next: CIOs  briefed their IT architects on the overall business strategy and the IT architects bullishly defined what was needed to deliver the strategy.  However, alongside the CIO on the board, were the other directors that ran operational departments and they needed to define their departmental strategy.  What happened next should have been predicted: when those operational directors went to IT to ask for support in developing their ideas, they were told that IT already had the answers.  When both solutions are analysed independently, IT had ignored business critical issues in developing their solutions and the business hadn’t (had the chance) to address IT concerns.  So what I got wrong in my support for CIOs joining the board, was that IT now viewed themselves as being the way to deliver strategy, rather than a supporting actor.

I have witnessed discussions in which an IT architect sets out how the business needs to change to accomodate a new peice of IT that’s the silver bullet to delivering the business strategy.  Those meetings never go well but there had clearly been hours of expensive IT architecture work put into the definition, so much so that the operational directors often wondered why those architects weren’t dealing with customer issues.  All of that IT architecture ignored one fundamental fact: IT don’t run the business and often don’t have the best view of how to move the business forward.  It’s also true that, all too often, IT architects want new technology, rather than improving what already exists or, heaven forbit, admitting that their last bright idea didn’t deliver the business benefits that were promised.

So what are IT architects responsible for ?  My list would be:

  • defining the the lifecycle for each of the applications and providing that information into as an ‘influence’; 
  • developing ideas on how to reduce the TCO for IT platforms;
  • defining IT principles, by decomposing the business vision;
  • setting IT standards;
  • governing the IT aspects of solution architectures; and
  • delivering IT solutions, hand-in-glove with the appropriate business unit.

However, in all other discussions on how strategy can be implemented, IT architecture should to defer to the business units and explain the impact of IT principals to the business units.  For example, moving to a cloud-based implementation model might form part of a principal. However, the move to cloud has an implication on how IT is paid for (i.e. OPEX vs CAPEX) so that too should be fed into the enterprise motivation model as an influence.

That approach ensures that IT Architects speak on the subject on which they are most knowledgeable – IT.  That IT Architecture is a specific activity in the TOGAF model for a reason – it takes knowledge of the existing IT landscape and knowledge of new technologies.  There are many IT Architects that understand the application landscape across the whole enterprise and they’re often called ‘Enterprise Architects’ which is a confusing term.  I believe that the Enterprise Architects perform their activity, in TOGAF terms, in the Vision and Opportunities and Solutions activities and then lead on through the rest of the ADM activities.

So when should IT architects ben involved ?  In my view, the ‘proper’ sequence of events, after strategy has been developed, is for the Enterprise Architects (EAs) to help the business executives develop the strategy to the next level of detail and update roadmaps documentation as appropriate.  The EAs develop a new ‘to-be’ operating model and communicate with the various architect specialisms on how that new operating model can be realised and then gain agreement on the order in which change should be implemented: essentially ‘Agile architecture’ or my definition of it anyway.  If an incremental enhancement requires a complete refit of IT platforms then the discussion becomes one of cost/benefit analysis, not one of who is best placed to refine strategy.

Business motivation

This post is part of the ‘Architecture Models’ series.

What makes an organisation do anything ?  What causes it to change ?  If the internal and external forces on an organisation were clearer, would it lead to simpler change ?  I’ll try to answer the first two questions in this article and maybe you can answer the third in the comments section below.  This article is about documenting the enterprise’s reasons for changing; their motivations.  Unsurpringly, there’s a model that can be used to document these motivations: the ‘business motivation model‘ from the Object Management Group.  I use this model frequently because it helps me to define wby an activity is happening, that leads me to understand the Critical Success Factors and so it’s simpler to make the activity a success.  I use the word ‘activity’ advisedly because this model is nicely particular about its definitions for words.  It correctly defines vision/mission, goals/strategy, objectives/tactics and those are terms that I find executives misuse and then sow confusion by misusing them in communications.  Using this model, in your head if not fully, helps to structure thoughts about the reasons for change and stops that confusion.

I encourage you you read the official OMG definition but I’ll introduce the fundamentals in my own words here. The basis of the model is the following structure:

BMMOverview

Business Motivation Model Overview (v1.3)

Enterprises define the ‘End’ that they want to reach, which is called their ‘Vision’, considering assessments of external influences as part of the process.  The ‘Vision’ is decomposed into ‘Desired Results’ and those are delivered by ‘Means’.  ‘Means’ can either be transient, such as a strategy to be executed, or permanent, such as a new business rule.  The enterprise is supported by a common vocabulary (aka a glossary) and enacted by a parts of an operating model.  It’s quite simple really: ‘Means’ deliver ‘Ends’.

There’s no definition of how often ‘Ends’ should be updated but it’s quite clear that it’s necessary.  If an organisation doesn’t have a Vision then it doesn’t need Means and if the Vision doesn’t change then it isn’t taking account of influences.  As an aside, I find it odd that not every company has a clear vision.  Published or not, it’s such a fundamental building block of Enterprise Architecture, maybe a pre-requisite, that I’ve declined work in organisations that couldn’t articulate their vision.

An approach that I’ve found to work is to use the model iteratively: define the motivations at the highest level of the organisation, and the Means to deliver them, and then decompose the Goals into sub-goals that are distributed across the organisation and then define the Means to deliver those sub-goals.  The Enterprise Architect holds the relationship breakdown between the different goals and can show how a change in one affects the others.  There aren’t many organisations that define strategy and plans with this much rigour, possibly because the executives haven’t been taught the tools necessary to structure their thinking, but from an Enterprise Architecture perspective, it’s both vital and enlightening.  Just imagine being able to explain to anybody in the organisation, those that wanted to know anyway, how their activity was part of a bigger plan, exactly how they fitted into the organisation and who changes their work impacted.  It’s a powerful tool, when used correctly and when the model is maintained over time.

The business model canvas

This post is part of the ‘Architecture Models’ series.

The business model canvas is a very high-level view of en enterprise.  It lists what the enterprise does, its interactions, resources and partners / suppliers but no more detail than that.  It’s a sort of X-ray of the organisation that shows all of the working parts but not how they work together.  You might think that it’s worthless but, if you have some knowledge of the type of business, then it’s a way of documenting an overview that’s easily consumable by non-architects.

Business_Model_Canvas

The lists of what the business does are just lists, often bullet-points.  There’s no correct or wrong way to write them just so long as they make sense to whoever reads the canvas.  The canvas has been used by many years (it was documented in 2010 by Osterwalder, Pigneur et al.) and so has become a standard template.  As such, the template headings provide a prompt of what needs to be documented.  There’s an strong overlap with parts of the Zachman framework but I prefer the business model canvas because it’s more consumable by non-architects.

If you were starting a new business then this diagram is a useful overview of your proposed enterprise.  If you’re starting to understand an existing enterprise or a department in an enterprise then the business model canvas gives you a place to write down the things that you find.  What it doesn’t do is explain how the different parts fit together; that takes an Operating Model.

What is an enterprise ?

This series is about the Enterprise Architecture models that I use day-to-day.  It takes a top-down look at the different models that describe business, application and techology architecture and my commentary on where and how I’ve found them useful.

This post is the starting point for the series so, to get started, I need to define an ‘enterprise’.  For the purposes of this series, I’m going to define an Enterprise as:

  • a balance sheet

delivered by

for a company that can be described by a

that operates as one or more

  • business verticals

and which is measured day-to-day by a

  • balanced scorecard

and wants to change according to set of

It is harsh to characterise an enterprise as being just a balance sheet.  However, in a capitalist economy, when viewed from the outside, companies are characterised by their balance sheet.  From a social perspective, they might provide employment for tens or tens of thousands but they exist to make money, even if it’s just sufficient money to pay those wages.

I’ll admit that architecturally, this definition is ‘clean’: starting with, for example, an ‘operating model’ makes the flow of words more difficult.

What is Enterprise Architecture ?

The term ‘Enterprise Architecture’ confuses people.  What does an ‘Enterprise Architect’ do ??

I was challenged recently to explain the difference between IT architecture and Enterprise Architecture.  My immediate answer was that Enterprise Architecture takes a broader view than IT but that answer was difficult to defend in a discussion with an IT architect that delivered architecture across a broad scope.

There would seem to be a common misapprehension that an Enterprise Architect is a business, application or technology architect that has a broad scope.  My definition of Enterprise Architecture, and Gartner’s, is that an Enterprise Architect defines the way in which an organisation operates, through models and abstractions, and uses those models to facilitate quick and efficient business change.  The models cover the business functions that exist in an enterprise and they’re not just from an IT or process or information perspective, but a holistic view of all three perspectives across the whole enterprise.

The definition of the way in which an organisation operates is often called an  ‘Operating Model’ so an activity for an “Enterprise Architect” is the documentation of operating models.

When Enterprise Architects have this view of an enterprise and the models to depict it then they can use them to support the refinement of strategy.  Many executives understand their part of the enterprise well and can manage it but don’t necessarily have the “helicopter view” necessary to make change because they don’t always understand how their function affects the rest of the enterprise.  Enterprise Architects are there to use their models to make sure that the impact of change is understood and to help executives refine their strategy.

Finally, I should answer the question of whether you need an Enterprise Architect.  If there is no change in your enterprise then the answer is ‘No’, you don’t.  Of course, the converse is true too – if you want your business to change quickly then you need more Enterprise Architects.  Now show me a enterprise that doesn’t want to change …..

Series introduction

There are many different Enterprise Architecture models and it’s hard to know which ones to use in which situation.  This series (Architecture Models) that shows the Enterprise Architecture models that I use day-to-day and I will describe why I’ve selected a particular model and explain how I found it useful.

Many of the models inter-relate so I’ll explain how they link together and then how they can be used to decompose an architecture from the most generic to the specifics of your enterprise.  I’m not intending to create a new model but we shall see whether this series ends up creating a meta-model of models.

The series will start with business architecture and then move into technology and information architecture, as you’d expect from TOGAF.