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:
- 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.
- 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.
- 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.