What needed to be monitored to get better Governance
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.
I'm usually splitting governance into three types:
Formal: Creating hooks in IT SDLC, IT processes and business management processes to keep track on changes and conduct reviews where needed.
Active : Participant actively in IT projects (as part of the team) to catch and fix compliance issues when they are arise and not after they are solved, and the project is ready to deploy.
Passive : create set of IT projects compliance reports based on compliance parameters to create visibility of architecture compliance and pressure on projects.
The formal and the active governance required trigger points in different enterprise processes to know all the changes in the enterprise four domains, so we can react in the right way. Listed below are the triggers that I getting use to put and the data that I'm monitoring.
Requests for new projects :
What we have: knowledge of potential projects
What we can do: make sure that new projects fits into our portfolio and roadmap.
RFP / internal analysis :
What we have: Business capabilities, business processes, logical information model, relation to other systems, externals business units .
What we can do: make sure that the project using EA language. Validating EA repository accuracy (new building block instances and relations). Make sure the project fits EA guidelines.
Architecture Review
What we have: Main project modules, relations to other systems, requirements from technology layer and definition of non functional requirements (response time, data volume, auditing, security, availability, etc').
What we can do: Validate compliance to blueprints and principles. Validating EA repository accuracy (new building block instances and relations)
Design review
What we have: Low level derails of project implementation (Not in EA level).
What we can do: Validate that project still keeep compliance after going down to details and solving problems that the project wasn't aware of in architecture phase.
Code review
What we have: Code written to implement design (Not in EA level)
What we can do: Design is good but implementation might change it significantly. We want to Validate compliance of the finished product.
Deploy to production
What we have: Applications, databases, servers, products, technologies, storage devices , communication devices.
What we can do: Validate our repository against deploying data and make changes of the as-is architecture (if necessary).
Deploy of new change / enhancement to production
Same as deploy to production just this time we want to know just about the changes that has been done to the existing project
New capacity planning of databases/storage/servers/network
What we have: databases, storage devices, servers and network devices.
What we can do: align between EA to-be architecture and reality. Making sure that capacity planning following architecture blueprints and principles.
Purchasing of new Product, database, storage, Server, Network device
What we have: Products , Databases, storage devices, servers and network devices.
What we can do: align between EA As-IS architecture and reality. Making sure that purchased goods are done by following architecture blueprints and principles.
Personal changes in IT (change IT group, leave IT or enterprise)
What we have: Responsibilities and ownership.
What we can do: Validate IT and business assets responsibilities and ownership.