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.

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.

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.

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.

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.

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.

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!

 

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!

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.

Functional Dependency Map

Edit: We’re currently reviewing our FDM to see if it can be improved.

 

How can you ensure that your road-map of projects stays robust and on target to deliver against your strategy? The one thing we can be certain about is that our road-map is in a constant state of flux. Schedules change, scope flexes, new projects are added and existing projects stopped. How do you help ensure delivery against your target architecture?

A good starting point is your knitting pattern but that only tells you that there is a potential dependency between two projects – it doesn’t tell you the nature of the dependency. A Functional Dependency Map (FDM) expands on the knitting pattern to give you more information about the links between your projects.

What does an FDM look like?

In this example, we already have two projects on our road-map: project 2 is enhancing your customer data store to provide support for corporate customers; project 1 is building some automation to create a customer record on demand. You’ve already established that there is a dependency between these two using your knitting pattern and the functional dependency map makes that explicit. Project 1 has a dependency on project 2 if your automation is going to be able to create corporate as well as retail customers.

Project 3 has just been initiated to provide online support for retail customers and part of that is to allow retail customers to sign up for an account online. Project 3 is dependent on the automated account creation being built by project 1 and, therefore indirectly, on the corporate customer build in project 2. You probably could have seen the first dependency quite easily, but the FDM also exposes these chains of dependencies. You can know see that any delay to the corporate customer build could affect your online retail customer build.

So, if that’s what an FDM looks like how do you use it?

Use case 1 – Get your projects talking to each other

If there are cross-project dependencies, then your analysts need to be talking to each other to ensure that their requirements and design are consistent and build towards the end goal. Also, your project managers need to be talking to each other about schedule – does the later delivery need to wait until the earlier delivery is in production or is a firm design enough to start with? Your test and deployment guys also need to be thinking. Should these be tested and deployed separately or can they be done together to accelerate value delivery for the business?

Use case 2 – Adjusting your road-map

Road-maps change for three reasons: addition of a new project; stopping an existing project; or change to an existing project (e.g. scope or schedule). Any one of these changes can have knock-on impacts to other projects on your road-map. The FDM allows you to quickly identify those knock-on impacts. If you’re stopping an existing project was that project delivering something that another project is dependent on? If an existing project is slipping what does that do to the schedule of dependent projects? If you’re adding a new project, what new dependencies are you creating?

Use case 3 – Program level risk and issue management

Most change delivery teams are pretty good at managing risks and issues at the project level. Where things start to get a little flakier is at the program level. We’re all aware of the concept of a critical path for projects but how often have you seen a critical path for a program? An FDM is not strictly a critical path for a program since it doesn’t include schedule, however, it’s quite close to one; and if you do find yourself using it for that purpose there is nothing to stop you adding schedule information to the FDM provided you’ve got a mechanism for keeping it up to date.

Clearly, there are other dimensions to all these decisions – not least code, environment and resource contention – but unless you have a clear picture of the functional dependencies on your road-map, you don’t have a robust road-map.