Mike Kavis posted another great piece on why we should use Enterprise Architecture. As always, Mike has some real gems in his post. Here are a some:
- “It sounds to me like people have a technical solution and are now looking for a problem to solve with it. It needs to work the other way around!”
- “Well, coming to the business with technical solutions asking for help to justify them with business drivers is not alignment.”
- “At this point the ROI should be much easier, because the solutions were driven by the problem statement(s), not the other way around.”
- “Without this alignment, IT will constantly struggle to sell technical solutions to the business and come up with appealing ROIs.”
With the recent economic situation, business leaders are looking more and more to IT leaders to help enable cost savings and business performance. In my regular meetings with my business colleagues, this is becoming a consistent theme. The only way this will happen is for IT leaders to sit with business leaders and understand their issues and problems. Once this problem is understood, then the IT leader can bring to bear the appropriate technology solution. The ROI is put back on the business (where it belongs) and how the problem is solved not on the technology that enables the problem solving.
I am interested in how to get the IT leader to the “table”. Traditionally (and most commonly), business decisions are made with little IT input. We only hear about it after the fact and need to respond. How do we as Enterprise Architecture professionals demonstrate our value, gain the trust and build the partnerships with our business (in my case education) colleagues?
I have some suggestions:
- Establish IT Governance – this is the prime avenue for engaging the organization on what the IT “black box” (and for us toolkit) is about. It puts a focus on business and risk related problems the organization faces and leverages our technology capabilities to solve them. A critical factor here is that the IT Governance groups need a budget of their own so the final decision rests with them (as does the accountability!). IT Governance is about “Doing the Right Things”. Think of this as “efficiency”.
- Start an EA Practice – there is no need to buy expensive tools and go into the deep dive of documenting everything. Start simple by creating some guiding principles. Vet them with the IT Governance groups. Then communicate them regularly so the Guiding Principles become part of your organization’s common language. Enterprise architecture is about “Doing Things Right”. Think of this as “effectiveness”.
- Build an Application Portfolio – we have had quick wins and success by starting with what we know. Build an application portfolio with some simple attributes. Excel works great and migrating to Access for query capability helps too. Again, don’t boil the ocean … document what you need to show value and linkage/alignment to the business. What I mean here is “Every application should have an Executive Sponsor and a Business Owner”. This is Alignment 101. Once you have this built, take the data belonging to a specific Executive Sponsor and show them what they are responsible for. It is a pretty interesting discussion. Inevitably, the discussion turns to:
- What services do these applications support?
- Where are we not supporting services we deliver?
- Do we need to continue to support services that are not needed?
- Build a Service Catalogue – we built one for our IT Services department and it has paid great dividends. Now I am using this as a model to help our Human Resources department build their own Service Catalogue. I will blog further on this process.
Great post Mike! Keep it coming.