EBA – Art or science?

A very interesting post from Nick Malik over at Vanguard EA recently. Go read it first and then come back, I’ll wait.

I was touched by his (almost) cri de cœur at the end…

Today… I do not know

The post has drawn me back here to write something for the first time in ages because a) the subject resonated very strongly with me and b) I wanted to cheer him up a little!

All models are wrong…

…but some are useful. This quotation from statistician George Box is a touchstone for my more formal architecture work. The sentiment being that architecture models inevitably are a simplification of the real world in order to try and generate insight. The balance that always need to be struck is whether the gain in insight is offset by the loss of fidelity compared to the real world.

A variation of this looks to the fact that the business is constantly evolving underneath you and sometimes you don’t even know all of the change that is happening. I have heard architects bemoaning the fact that businesses don’t come with configuration management and version controls – OK, I own up, I’ve also done this myself! But unless the change is “architecturally significant” does that matter?

So, in the previous two paragraphs, I’ve talked about two things that are not susceptible to formal, rigorous architectural modelling: balances needing to be struck; and, defining something as architecturally significant. This, hopefully, sets the theme for the rest of the post and starts to speak to the title as well.

In his post, Nick makes the following observation…

…it should be a clarion bell to any architect who drinks their own lemonaid and believes that an enterprise is a construct. It is not. An enterprise is a community of organic elements, each of which grow and change according to organic principles.

I’d like to buy that man a drink for saying this. Although presumably not lemonaid?

Contextual sensitivity

No business change or architectural activity happens in a vacuum; it is always happening in the enterprise’s current “context”. I’m using context here to refer to the (often) subjective, people related, not necessarily rational, sometimes temporary, emotive and/or political aspects of the organisation. Where is the people and leadership headspace at right now?

Sometimes, elements of this context need to be challenged because they will block the enterprise from realising the strategy; other times the game isn’t worth the candle and we’re better off just accommodating it. What is common to all of them, though, is that I don’t think they are easily susceptible to formal modeling or rigorous, rational analysis.

As a side note, it might be an interesting exercise to see if some of these aspects could be modeled using something like the OMG Business Motivation Model. However, I suspect that semantically these aspects are probably internal Influencers which, in my mind, come across as second class citizens, compared to the first class artefacts of Means or Ends.

In my mind, it’s the mark of a really good architect that they can successfully navigate these waters in the absence of the models that explain them. And, no, I don’t necessarily count myself in that group as, while I can recognise them, I’m not always successful in handling them well!

Is it the enterprise or is it the people?

Nick’s post talks about the self organising enterprise but I think it might be worth thinking about whether the enterprise is organising itself or whether the people in the enterprise are organising themselves via behaviours that are manifesting as enterprise changes.

In either case we, as architects, would do well to acquaint ourselves with seminal works such as Mullins’ Management and Organisational Behaviour and Handy’s Understanding Organisations. Neither of these offer formal modeling approaches and I’m not aware of any works out there that do model enterprise level behaviour. If there are any I would be very interested if somebody could point me at them.

On the other hand there is wealth of material out there modeling people behaviour. Here’s just one example which, while dealing with the domain of healthcare, outlines at least 3 behaviour modeling approaches. Two key challenges will exist in adapting any of these:

  • Is it possible to adapt these models to extrapolate the impact on enterprise behaviour? and
  • What would be needed to integrate these new models with more established EBA modeling techniques and artefacts?

Now, answering these challenges is a whole heap of work and I don’t pretend to have any answers here or even know whether this would be a fruitful avenue to pursue. What I do know is that I agree with Nick when he worries that “our guesses are missing so many of the influences that actually drive enterprise structure and behaviour”.

In the meantime…

We are where we are and we would do well to heed Nick’s message that our current state of the art has significant flaws that we ignore to our peril.

I don’t know that we need to be too disheartened though. Reflecting back to our building architecture forebears, I have never seen an architecture blueprint for a building that explicitly includes cultural, societal, behavioural or political impacts on the design. These are the contextual elements that have informed the architecture blueprint but they aren’t actually shown in the diagram. Are we any different?

Just some thoughts from a rainy and windy UK inspired by people thinking better and more deeply than I do.

Posted in Uncategorized | Leave a comment

Hello world…

…although I’m not sure whether anybody will be reading this. I can’t believe it’s nearly a year since I last posted here…

*flaps a cloth around and sneezes at the disturbed dust*

I first started this blog to help analyse and codify my thinking and that’s probably the reason I’m back again. You see, I’m in a bit of a rut at the moment, wondering whether this enterprise business architecture journey we’re all on is actually the right one.

Are we on the right train? Is the track headed in the right direction? Should we actually be on a train at all, or would we be better off on a ship?

That’s all a bit nebulous and you probably have no idea what I’m talking about. To be fair to myself, I’m not sure either – that’s why I’m back at the keyboard to try and work it through.

I think I can distil my concern down in the following two paragraphs.

On one hand we have simulations like economic models of supply and demand, or efficient portfolio investment models. Simulations tend to be more dynamic and predictive; if you do this, then that is likely to happen. This prediction is commonly where their accuracy starts to break down because, inevitably, the real world is more complex than the simulation. Nevertheless they have enough “truth” or provide enough insight to be fundamental to the business world. There is no question of whether managers trust them or believe them; they are simply taken as implicit facts.

On another hand (I reserve the right for my metaphor to have more than two hands should that be required in future) you have architectures. In keeping with their construction parentage, they are a largely static picture of “how the world is now” or “how the world will be in future”. They can allow users to develop their own insights but those insights are extrinsic to the architecture picture. There is no reactivity that allows you to change a what-if parameter and see the result. Unlike the simulations they are not taken as gospel fact and we are struggling to get business managers to engage with them.

Architectures are, without a doubt, useful but my worry is that, unlike the simulations I referred to, their insight is not immediately apparent or useful to business managers. Are we right to be on the architecture train, frantically laying tracks in front of us as we explore?

Or would be be better off on the simulation ship?

This is, I think, the question that is bugging me. It’s going to take more than one post to work this through so please bear with me. It may well be that this isn’t the right question but hopefully that too will become apparent as we go. If there is anyone out there still reading, please feel free to chip in with your own thoughts.


Disclaimer: I’m very aware that by using “simulation” for the insight version and “picture” for the architecture version I could be accused of pejorative language and of defining the terms to suit my own argument. That is definitely not my intention. My intention is simply to create a distinction between a reactive (dynamic?) model and a largely static one.

Posted in Controversial | 1 Comment

Let it go… and let it break

I guess our business is much like any enterprise in the sense that the pressure to find that extra saving, that extra efficiency is always present. When combined with the increasing sophistication of end user computing (EUC) tools this can lead to challenges for architects. Screen scrapers, macros, those huge spreadsheets that only one person understands enough to maintain? Yeah, I guess these are facts of life for many organisations.

As the sophistication grows it’s tempting to try and bring some form of governance to bear. To try and turn the tactical into, if not strategic, then at least managed tactics. But be careful!

Any form of governance has an overhead associated with it; be that time, effort or, yes, bureaucracy. While this overhead is an investment when it comes to areas with high business value or importance it can be a killer for lower value or importance activities. Quite literally, instead of trying to improve business value you can end up stifling it.

Businesses deploy EUC tactically because they can. For a small investment they can get small incremental improvements; business efficiency is often about improving 100 things by 1% not one thing by 100%. As well as the risk of stifling these 1%s, what’s likely to happen is that another “business improvement” area will spring up elsewhere without your governance oversight. Why? Because they can and the need for those 1%s hasn’t gone away.

Sure, you need to set some ground rules to protect your core; things like running macros at off peak times or forcing a wait cycle after each transaction submission. But once you’ve protected your core let it go. Let the business get their 1%s. Let them be as creative as we know they can be!

But be clear with your management team. By letting it go, you are also saying “I will let it break. I do not give any commitment that future changes will take into account your EUC. If you choose to improve high value or importance business activities like this, then on your own head be it”.

Provided you are clear about this last piece then the business is free to chase those small efficiency improvements that they need, without risking the business and without consuming your time in the governance of low value activities.

Let it go… and let it break.

Posted in Controversial | Leave a comment

Functional Dependency Map – Follow Up

We’ve used a Functional Dependency Map for quite some while now to track risks and dependencies across our roadmap.

Once every 4 weeks we get the full project management team together for an hour to run through the dependencies with a view to checking two main things: firstly, is the supporting project still on track to deliver in time for the dependent project; secondly, is the supporting project still delivering the right scope for the dependent project.

It’s generally a useful session but is particularly valued by the higher level project managers. What they say they really appreciate is that all the dependencies across the roadmap are set out on a single page. I’d guess that there is some external interest in this area as well since the top 6 search terms for the blog are all along the lines of “project dependency mapping”.

This is just a note that we’re currently reviewing our functional dependency map to see if it can be improved in two areas.

Explicitness: While our current approach identifies that there is a dependency, it doesn’t explicitly state the nature of that dependency. As a result we sometimes waste time in the session redefining what the dependency is before reviewing it. Apart from the inefficiency, this also suggests that the dependency is not being actively managed outside of the review sessions. We clearly need to improve this.

Parallel as well as sequential: Our current approach supports sequential dependencies. In other words, project A must deliver this capability increment before project B can extend it. However, sometimes there is more of a parallel “dependency” [1] where two projects are incrementing a capability at the same time. An example would be where two projects need services that retrieve similar data. These two projects should be talking to each other to ensure that the service design is well scoped and efficient. Our current meta-model doesn’t have the semantic elements to support this concept of parallel dependency.

We’re therefore reviewing the model and it’s underlying meta-model to see if we can improve in these areas. We’re also taking the opportunity to see if we can reduce the cost of maintenance by using some tooling like Essential Project. I’ll make another post here when we’ve finished the review but, in the meantime, if you have any tips or pointers I’d be delighted to hear them!

1. I’m aware that parallel is technically not a dependency but project managers use the term to refer to links between projects so, because this is a tool for them, I’ll roll with it.
Posted in Delivery Mode, Techniques | 1 Comment

Analysts and architects

In a previous post I talked about how we segregate the roles and accountabilities of business analysts and architects in our organisation. I also stated my belief that the “business analyst and architect role are not quite as far apart in terms of skill-set as is sometimes claimed”. Since then I’ve had a few questions which can be summarised as “So, what is the difference then?”

I must admit I struggled to find a good answer to this, until recently. I was working with a good business analyst and I had a bit of an epiphany. The context is the analysis and design of a new e-commerce application that will be implemented alongside an existing suite of e-commerce applications facing off to the same end user. In particular, the login and authentication aspects of that new application.

We are implementing “captcha” codes for this application in response to a change in the security policy while a separate project will be retro-fitting captcha to all existing applications. The use case path under discussion was “what happens if the user fails to correctly captcha after three attempts?”

The implementation had two main architectural flaws: technically, the captcha failure was being handled by the application itself, rather than in the authentication framework; and, functionally, it was being handed off to a specific business team which was different to the central team who handled the same scenario for password failure. But I was having problems explaining this to the analyst who couldn’t see anything wrong – “It worked didn’t it?”

The business analyst’s take on this:

  • This component should have all the functionality the user will expect;
  • It must comply with our security policies;
  • It must comply with our usability and brand guidelines;
  • It must cater for all “happy day” and “rainy day” use case paths.

My (the architect’s) take on this:

  • Logically this capability is about finding out who the end user claims to be and then satisfying ourselves that this is indeed the case;
  • This is a generic component that needs to be consistent and reusable;
  • It has hygiene value for the customer – it needs to be there but mustn’t get in the way of the value they are trying to get to;
  • In the context of an interaction with us, the customer should only ever be asked to do this once.

It wasn’t until I sat back and mentally drafted the above bullet points that I realised why I was having problems. We were both using the same analytical skills on the same problem but we were looking in two different directions.

Analyst Architect
Tends to focus on physical implementation
Tends to focus on logical abstraction
Tends to focus in on the functionality of this capability
Tends to focus out to the relationships with other capabilities
Tends to focus down on the detail of the capability
Tends to focus up to the use context of the capability
Tends to focus on completeness of the capability
Tends to focus on the value of a capability
Tends to focus on whether the capability works
Tends to focus on whether the capability is reusable

I’ve deliberately used the words “tends to focus” because this is a spectrum. You will get positions along that spectrum and you must have coverage of the whole spectrum. But, if you need to answer the question “does this person operate more as an analyst or an architect?” you might find the table helpful.

Posted in Delivery Mode, Philosophy of EBA | Leave a comment

Analysis and architecture

Note: I originally titled this post “Analysis vs. architecture” but deliberately changed it based on the tone of the post as it emerged.

So, I’m not quite sure what inspired this post from Nick Malik but it certainly provoked reactions! Kevin Brennen from the IIBA responded very quickly with a detailed post citing numerous instances from the BABOK pointing out a lot of similarity between business analysis and architecture activities. In a comment to the original post, Tom Graves also pointed out that it may be the thought processes or weltanschauung that differentiate (or align?) the two roles.

In a follow up post the following two questions are asked of business analysis and architecture:

a) Is it better or worse for these roles to be independent?
b) When both roles exist in the same organization, how do we prevent confusion, clarify accountabilities, and make both roles effective?

Better or worse?

Setting aside time as a constraint, my response here is: someone who has the clearest view of the architectural needs is already well placed to steer the analysis towards meeting those needs. I agree with Kevin that the business analyst and architect role are not quite as far apart in terms of skill-set as is sometimes claimed. It does require that single person to be able to look “up” to analyse the strategy and capabilities and to then look “down” to the detailed implementation of their realisation. In my view, however, that is more a difference of mind-set (and experience) rather than skill-set.

But… I now come back to my caveat about the time constraint. I’m currently in a team of 4 business architects working with a team of around 30 business analysts. My current assignment is as an architect for a 2 year program of 4 projects (although the inevitable “phase 2” is being talked about!) working with a team of 7 business analysts. Would it be better or worse if I tried to do my own job and that of the 7 business analysts? Would it be better or worse if the 7 business analysts all tried to do the business architecture in addition to the 4 people who have been given it as a day-job and on top of their own day jobs? I would argue worse in both cases.

So, sometimes it’s a necessary evil for the analysis and architecture roles to be separated. The business needs (I need!) multiple business analysts to get through the volume of work; but the business needs (the analysts need!) a single steer on the architecture.


The table below sets out how we generally segregate accountability between the architect and analyst. Note that you can simply substitute “roadmap of change” wherever you see “program” if that is better suited to your situation.

Architect Analyst
Responsible for the value delivered across the whole program
Responsible for the value delivered by individual project scope
Works with project management to scope and schedule capability increments across the program
Works with project management to schedule capability deliveries within the project
Agreeing with the sponsor the budget to be spent on each capability increment
Delivering within that budget or flagging risks of over/under spend
Advising the sponsor and project management on capability trade-offs at program level
Advising the sponsor and project management on alternative delivery options for a capability
Ensuring requirements are balanced according to business value across all capabilities being delivered
Ensuring requirements are proportional to the business value of the capability being delivered
Ensuring that all the “moving parts” work together – cross project dependency management
Ensuring that a particular moving part serves its purpose – inter project dependency management
Working with IT architects to resolve business and IT architecture concerns
Working with IT analysts to resolve application/component concerns


Clearly, this requires close collaboration between the architect and the analysts both formally and informally.  Our starting point for the formal communication is the Business Architecture Briefing backed up by our “knitting pattern” and functional dependency map.

Informally, it’s really just about working as a team – I and the senior business analyst on each project get together at least once a day – and trusting each other. I know I can count on them to flag with me when things are going pear-shaped and they know they can count on me to fire a rocket at the business if they need me to.

It’s not about seniority either. I would, and have, happily worked for business analysts in the reporting chain when they’ve asked for architecture support. It’s just about understanding that the analysis has to flow from the architecture – not the other way around. It’s all about communicating between the two formally and informally to get the job done.

That, after all, is what we are paid to do.

Posted in Controversial, Delivery Mode | 2 Comments

Process or Capability Architecture

An interesting post from Nick Malik recently about how process architectures and capability architectures are different – picking up on an article from Paul Harmon. I’ll be very interested to see the promised “later blog posts”. In the meantime, though, I’m dealing with something at work that really emphasised some of the differences between the two so I thought I’d share it here.

We provide services to distinct groups of individual customers and those services commonly need to be tailored to those distinct groups. We currently have a project underway to extend that tailoring to our web presence. The first capability increment we are developing is the ability to deliver bespoke web content based on the group the customer belongs to.

In capability terms this can be encapsulated quite neatly into the ability to “Deliver bespoke web content based on customer groups”. This is something that is meaningful to any member of the top table and can equally be used as a scoping statement for the delivery teams – be that business analysts, project managers, test managers, solution architects or whoever.

When we get into the detail of the delivery then, absolutely, things become more complex. We’ve identified that we will need, at a minimum, the following supporting processes:

  1. A process to develop, test and deploy new content;
  2. A process to understand what content is currently deployed and, periodically, to get it reapproved;
  3. A process to understand what content was used for a particular user at a particular point in time (non-repudiation);
  4. A process to retire content that is no longer used.

In addition, the bespoke web content capability will be used in multiple, customer facing (primary) processes and capabilities – so each of those processes will need to be updated as and when they take advantage of the new capability. Now all of this has to be worked through in the detail of the implementation of the particular project. But how relevant is the detail from an architectural point of view?

My top table doesn’t care what processes we will have to put in place to deliver this capability – all they want to know is can we do it, yes or no? The processes that will use this capability, similarly, don’t care about how the content is managed. All they want to know is what can be done with the capability and how do I access that functionality? Neither of them care what is inside the “black box” only that the black box is there and what it is capable of.

So, to me, some of the fundamental differences between process and capability architectures are:

  • Capabilities allow me to talk to any stakeholder at any level (business or IT) about what is to be delivered without having to delve into the detail of the how;
  • Capabilities allow me to “architect by black box” creating reusable components of business capability where the implementation details are irrelevant to the capability consumer – this should be a principle that resonates with anybody who has been exposed to SOA;
  • Capabilities are a layer in the enterprise architecture that sits above process or IT system architectures – capabilities don’t care how they are realised and you can, for example, automate processes within the capability to improve its efficiency without changing the fundamental building block; and
  • As a result of that last point, capability architectures are much more stable than business process architectures, because they are insulated from the “how”, and so require less maintenance.

Now, where I agree with Paul Harmon’s point is that the concept of a capability has yet to achieve a fully agreed definition. I’m not sure that we will ever see that ultimate truth agreed, though. Is there a universally agreed definition of a process map, for example? One question that has parallels with capabilities is “How physical vs. logical should the process map be?”

What I do know is that capabilities have significant real-life benefits for me as a business architect and, quite frankly, I’ll take any edge I can get! Definitions will evolve over time as and when they get tested (and fail) against real world usage. I’m happy and grateful to be part of that real world testing.

Posted in Philosophy of EBA | Leave a comment

The art of compromise: Designing deliverable architectures

You’re initiating a new project: you’ve mapped it against your strategy contribution framework; you’ve done your capability mapping and updated your knitting pattern; you’ve planned your architecture increments; updated your functional dependency map; adjusted your road map; you’ve provided a clear steer on the shape of the business solution required with your architecture briefing… you’re good to go, right? (If you’re looking for guidance on those techniques check out my posts in the Techniques category)

Whoa, there Neddy! Hold your horses just a second. Have you made sure your architecture is deliverable?

By deliverable, what I mean is, can you give your business the right thing at the right time for the right cost?

A whole host of issues come to bear at this point, many of which are outside of the sphere of business or enterprise architecture: is there any resource contention between this and other projects (remember to include analysis, test, SME as well as development resources); is there any code contention between projects (commonly changes to the same IT application or database); is there environment contention (development, testing or pre-production environments); are you proposing anything new (technology, capability or approach) that affects the risk/reward ratio of the business case; are you creating dependencies on projects that are already in trouble.

All of these things (and probably more) have the potential to compromise delivering the right thing at the right time for the right cost – and they all need to be factored into making the right decision. Here are my three recommendations:

  1. First and foremost accept that your business architecture is one and only one view point on the right answer. Other parties will have equally valid view points. Unless and until you accept this don’t go to step 2.
  2. You need to involve other parties before base-lining your architecture briefing. At a minimum this will include your sponsor, your business project manager, your IT project manager, your IT architects and your test manager. Depending on your organisation you may have other stakeholders.
  3. Be prepared to iterate – but do it quickly! Prefer face-to-face rather than e-mail consultation, prefer a half-hour review this week to a 2 hour review in three weeks time, whatever it takes.

I originally titled this post “Designing deliverable architectures” then changed it to “The art of compromise” and then combined the two. Fundamentally they are the same thing. In order to get a deliverable architecture you will need to compromise – accept it, embrace it, work out in advance how you’re going to handle it.

Posted in Delivery Mode | Leave a comment

Business Architecture: How long?

Interesting article from Jeff Scott at Forrester. The headline for me was “63% [of survey respondents] thought they could create the core business architecture in less than two years” followed up by his caution that this was over-optimistic. I have a lot of respect for Jeff ever since I first read this article from him in Architecture & Governance.

Now, I guess all this comes down to what you define as “core business architecture”. But if you mean a stable, repeatable method and models that are fully integrated into strategic planning and the change road-map then I would agree that two years is quite challenging.

However, that doesn’t mean that you need to wait two years until your business architecture efforts can start to add value.

Sure, we had a couple of attempts at defining our capability model until we got it right. These were spread over a number of months and, speaking frankly, it’s still not quite where I’d like it to be. On the other hand, we got our strategic alignment framework up and running in a couple of weeks and, touch wood, it hasn’t really needed any change since we started it.

Maybe I’m an optimist but my response to this post was:

  • Don’t let the best be the enemy of the good – you can get value quickly from business architecture; and
  • If it really is going to take a while to get it right… best get started now then!


Posted in Getting EBA Rolling, Philosophy of EBA | Leave a comment

Help needed – How tactical should my architecture be?

Yeah, the title of this post probably didn’t give you much to go on did it? Let me explain…

We’re in a service business where our key customers are corporate customers rather than individuals. Our strategy calls for us to be penetrating the really big corporate customers – think top 50 FTSE, DOW, EUROSTOXX etc. and we’re having some success. But here’s the thing – most of the time, these guys won’t take off the shelf processes. They have to put in place their own processes to consume our services and each corporate wants to minimise the cost of their own processes. As a result, I’m seeing a lot of new requirements coming in that I need to match back to the architecture.

In the main, these are different ways of accessing the same core service/process which doesn’t require modification. As an example, we have a core process that is carried out by our BPM automation engine which is stable but, depending on the customer, needs to be initiated by an internal user interface, or by an external web user interface, or by a flat file that may be pushed to us, or pulled from an FTP server and so on. However, sometimes there is a specific requirement that doesn’t fit within any of our core capabilities (you can assume that our architecture is capability based rather than process based by the way).

So, I think I’m looking at having to assign attributes to my capabilities along the following lines:

  • Core – This capability is stable, repeatable and predefined; it will not vary by customer;
  • Strategic Flexibility – This logical capability must be capable of multiple, physical realisations that, for a large subset of our corporate customers, will vary and therefore requires investment to deliver that flexibility;
  • Tactical – This capability is something we agreed to do for a particular customer (or small subset of customers) just to win the business but is not something we want to spend a lot of time or money on.

One of the great advantages of blogging is that it gives you the opportunity to clarify your thoughts and I think I’ve clarified it to two questions:

  1. Is my 3-level categorisation appropriate or is there another, better way of approaching this issue?
  2. If it is appropriate, what should I do with the tactical capabilities?

Simplistically, anything we do as a business should be traceable to an entity in our business architecture and therefore every tactical capability should also be in the architecture models. But if you take that approach to its extreme, you’d be reflecting all the manual workarounds in your architecture which is clearly wrong and will simply add cost of ownership to your architecture models. On the other hand, I need to be aware of two things with the tactical capabilities: I need to give guidance that I need a Robin Reliant solution and not a Rolls Royce to the IT guys; and I need to monitor whether a tactical capability is moving into the strategic flexibility category (e.g. if multiple customers start asking for the same flexibility) and respond appropriately.

Should I or should I not include the tactical capabilities in my architecture? Have I or have I not got the right categories for my capabilities?


Posted in Philosophy of EBA | Leave a comment