Skip to Content

Proven way to run your Enterprise Architecture practice

After almost 10 years of enterprise architecture experience I think that I can provide a good advice. As everyone else (I assume) I had to learn all the lessons in the hard way (doing the mistakes 🙂 but eventually I managed to find the right combination that at least works for me.

The trick is to find the right combination between strategic and tactic work that need to be done by enterprise architects, together with the ability to show outcomes almost every 3 months. In order to do so I’m splitting the enterprise architecture work into three different work streams:

  1. Get familiar with your IT assets, learn your enterprise capabilities and aligning them: this work stream is mostly about modeling as-is, to-be, identifying gaps and creating migration plans. To make this work stream more practical and to show business outcomes out of it, I’ve learned that I have to focus on business capabilities (or business functions). The first step is to map business capabilities (Capabilities are “What” to business is doing. Not business processes that focus on the “How”) in hierarchal way (which brings good impact and it’s good outcome by it own). Next step is to map information, application and technology to the mapped business capabilities. After using business capabilities as a hook to put on enterprise IT assets, it’s pretty easy to see gaps and to create “to-be” and migration plan. To be able to generate products every three months, this approach should be done for each major business capability (level two) separately.
  2. Solving strategic (and painful) IT issues. The idea here is to collect all the IT issues (such as information modeling, integrated presentation of information, integrated queries, DRP, application portfolio, GIS, compartmentalization,  etc’) and to let your stake holder to prioritize them. After having the prioritize list start dealing with each task separately and in two steps. Step one should be focused on blueprint, policies, principles and constraints that should guide the technical solution. Step two should be focused on the technical solution.
  3. Governance: setting principles, policies, blueprints and migration plan aren’t enough to take your enterprise to the place you want it to be. You should be involved in the IT processes to be able to make your vision into reality. Two major events in any IT project that you should be involved in (be responsible of is much better opportunity) are: Projects approving and deploying finished projects into the enterprise production environments. Having control on those two events will help you to make sure that your migration plan being done in reality and to keep you mapping up-to-date. If you have enough resources to be involved in the developing process of projects, go for it.
Be the first to leave a comment
You must be Logged on to comment or reply to a post.