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 | Leave a 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.

Accountabilities

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

Communication

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?

Help!

Posted in Philosophy of EBA | Leave a comment

EBA and the Program Office

I recently had a chance to look into the detail of the P3O work being done by the Office for Government Commerce here in the UK. Now, while I don’t agree with everything they propose as best practice (more on that in another post) it did clarify something that I’ve instinctively felt for some time – architecture is a sub-set of the program office (PO) function.

That isn’t really the point behind this post though; the point behind this post is to explore why, when I mentioned this to some fellow architects, I got so much negative reaction:

  • You’re kidding, right? Architecture is about long-term planning, PO is about day-to-day reporting and delivery
  • No way. Architecture is about functions and capabilities, PO is about schedules and resources and stuff like that

Well, I’m sorry, but if you don’t believe that architecture is about delivery and if you believe that PO is only short-term then you’re doing at least one, and probably both of them, wrong!

Let’s take a look at what P3O aims to achieve (from their website):

  • Informed senior management decision making on strategic alignment, prioritisation, risk management, optimisation of resource etc to successfully deliver their business objectives (portfolio management)
  • Identification and realisation of business outcomes and benefits via programmes
  • Successful delivery of project outputs that enable benefits within time, cost and quality restraints.

Now, as a manifesto goes, I can sign up to that without much disagreement, but let’s break it down a bit. The first bullet cannot be achieved without a strong architecture function, especially as regards strategic alignment and business objectives. The second bullet also has strong links to the road-map and, therefore, strong links to the architecture function. The third bullet has perhaps weaker connections to the architecture function but still has links to selecting the right scope and the right solution.

But, and this is the clincher for me, look at how many times there is reference to “delivery”, “outcomes”, “benefits” and “objectives”. If our role as architects is to ensure the delivery of the right thing at the right time for the right cost – and if the best way of doing that is to plan, monitor and control the change road-map – then how can we not be part of the PO? How can we not be part of shaping and delivering the change agenda?

Maybe this is just my particular philosophy on things. Maybe it shows through in my post about process and people elements of an EBA function. But I truly believe that unless you are getting your hands dirty and are actively plugged into the mechanics of delivery you are not doing your whole job.

Posted in Controversial, Philosophy of EBA | Leave a comment