As an Enterprise Architect I naturally think that applying sound architecture principles can make good almost any business issue. However, when my youngest son broke his arm a week before our holiday, I wondered whether the application of architecture principles could rescue our holiday?
Fortunately for my son, before I’d spent any time thinking on this we whisked him to the hospital and the orthopaedic specialist did the job. Fixing broken arms, it would appear, is already a commoditised process needing zero intervention from architects.
I did later however realise a parallel I often see with clients. My son had been racing up the stairs obsessing about a small graze on his knee, looking for a band aid. He ignored our shouts not to run and when he got to the top, he promptly fell down the stairs. How often in business are we so obsessed with tactical and quick win solutions that we race ahead, ignoring the calls to be cognizant of the strategic picture and ending up causing ourselves bigger problems?
Action and reaction
In business when something happens, organisations often react tactically, not strategically. There can be lots of reasons for this, such as:
- Limited budget
- Organisational silos / limited mandate
- Time pressure
- IT capabilities and business needs not in alignment
Because we’re thinking tactically, we get limited feedback about our solution and it generally ends up as positive because we’ve done a good job with our implementation. What we haven’t realised is that our tactical solution has had a significant cascading effect which may take time to fully work its way out. When it does we get a delayed negative feedback and issues such as:
- Corrupted data
- Greater IT complexity
- Sub-optimal business process
- Greater costs to fix the issue
- Unhappy customers (both internal and external)
This is classic action and reaction loop.
Fixing broken arms
If your business initiatives suffer from negative delayed feedback, then it’s time to stop and think about how you’re going to fix this strategically. This is where Enterprise Architecture can help organisations to:
- Identify and refine stakeholder requirements
- Develop views of the architecture to communicate how concerns and requirements are going to be addressed
- Show which trade-offs are needed to reconcile the potentially conflicting stakeholder concerns Provide implementation governance to ensure that projects deliver what the architecture specifies
In the same way I needed a specialist to help my son, you’ll benefit from engaging an experienced Enterprise Architect who is able to bridge the business needs with the technology and ensure that decisions are made and architectures delivered with the strategic viewpoint in mind. The point is actually to stop the arm from becoming broken in the first place.
Do I really need an Enterprise Architect?
Sometimes I find executives are sceptical about the benefits and whether they’ll achieve ROI (return on investment) on Enterprise Architecture - ”Doesn’t my IT department do this already? Why do I need architecture?”
I’m sure the IT department does an excellent job but if things were going well then you wouldn’t be getting the negative delayed feedback. IT departments can fall into the tactical thinking trap just as easily as the business.
These days we also see IT budgets shifting from CIO’s to CMO’s. CMO’s don’t often have the years of good IT discipline behind them and may need help from someone who does, and can also speak both the business and IT languages.
If you’re not sure or simply think that architecture is too expensive then I suggest you start small. Once you start to see the benefits you can scale-up the architect’s mandate. By taking an iterative approach and being smart about where you start you can control your spend. Enterprise Architecture need not be as big and complex as many people mistakenly think.
You could also start with an external person to get you going and ultimately bring the practice in-house, although this would require careful managing to embed a sustainable capability and is whole other topic in itself.
Starting and continuing smart
As I’ve already said, Enterprise Architecture need not be big and complex. It’s not about locking your architects in a dark room, for them to emerge months or years later with a baseline of the entire businesses processes (many of which may well be already out of date). It’s about focussing on the specific business objectives and requirements you are trying to achieve. Limit your architecture projects to business objectives which are SMART (Specific, Measurable, Actionable, Realistic and Time-bound) and iterate your way through cycles of 4 to 6 weeks to achieve the best architecture.
Ultimately when you’ve decided on the benefits of good enterprise architecture, you’ll find yourself wanting to iterate it every 6 to 12 months as business as usual. New disruptive business models appear frequently these days and unless you’re agile, you won’t keep up with new innovations and technologies let alone get ahead of the competition.
So can Enterprise Architecture fix broken arms? Not yet, but I still have faith. What it can and should do is enable your organisation to lift itself above tactically reacting to business events and deliver strategic value.