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?



About EBAnous

EBAnous works as a business architect for a FTSE-100 company in the south-east of the UK
This entry was posted in Philosophy of EBA. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s