Vendors tend to publish roadmaps for their products. Those roadmaps include when the product schedule to be replaced with new version, when the product regular support will be replaced with extended support and when the vendor won’t support certain product version.

This time I'm sharing a list of EA values of mature EA practice. This customer is a leading company in the utilities industry with aggressive business strategy of merge and acquisition. as a result they have continues challenge of merging IT units together.

I saw Gartner's list and I simply had to write my own version (which is based on my experience).

1) Doing EA just for the sake of EA:  Enterprise architecture is a mean to reach a goal. If you don’t know what is your goal and how you'll use enterprise architecture to reach this goal, you fall into the most common and painful pitfall. There should be at least one goal like to reduce IT cost,  better planning and executing of IT, dealing with compliance requirements or even migrating legacy applications to new platform. If you cant provide clear goals and explain how EA is serving you, you're doing enterprise architecture for the sake of enterprise architecture. Regretfully doing EA for the sake of EA will bring your initiative to complete failure.

Collecting, modeling, validating and analyzing data from different domains to create to-be architecture in a form of principles, standards and blueprints are not enough to create successful enterprise architecture. The real challenge of enterprise architecture is the ability to make it happened in projects. If you can't find signs of enterprise architecture outcomes in running projects, all the work that you've done worth nothing. In this post I'll try to describe what are the main task that I'm doing to create successful enterprise architecture governance processes.