Enterprise Architecture’s fundamental purpose is to enable business outcomes by materializing business strategies into real solutions.
As we have discussed in previous posts, there are some important aspects to maturing your Enterprise Architecture practice such that it is able to positively impact business outcomes, and having an understanding of the business is obviously a key one! (It is unfortunate that this obvious aspect is lost to many of us..) But I digress…. Today we are looking at a worst practice that lures us into chasing after a shiny object, when there are more fundamental things wanting our immediate attention. This is especially true if you have just (seriously) started your EA journey.
A glittering, shiny, TOGAF compliant, Enterprise Architecture tool is quite an attraction:
Only if I could get all the software inventories, software life cycle information, artifacts, models and reference architectures in a tool, I would be able to sit back and watch it go to work for me. Want to know how many servers are on an obsolete operating system? Click of a button and you got it! Want to know how many software are about to go out of support? Click of a button and you got it! Want to know which reference architecture to use? Click of a button and you got it! Ah, just dreaming about it makes me happy 🙂
So Mr. Architect, what business outcomes would you have enabled by that? “Err.. ahem.. actually… well.. I think.. Let me think.. err.. arrgh!!” Can your tool help me increase penetration in emerging markets? Repeat “Err.. ahem..” cycle. How about reducing manufacturing scrap? Repeat “Err.. ahem..” cycle. How about increasing customer satisfaction, product quality, manufacturing flexibility? Rinse and repeat “Err.. ahem..” cycle many times over.
Not that Enterprise Architecture tools are not important, in fact they are very important once you know WHEN and HOW to use them to enable business outcomes. Used indiscriminately, they can do more harm to your budding EA program than good.