EA Governance is an elusive animal. Everyone talks about it, but very few organizations successfully implement it. It’s one thing to create a set of standards, but it’s entirely another to enforce them across the enterprise. Our organization has taken an incremental approach to rolling out a governance process. Using this incremental process, your organization matures into governance rather than going for a big-bang approach. Here are the steps we’re taking in our journey to EA Governance.
Step 1: Document
We started out with a bunch of “standards” that mostly existed in the ether – what you might call “de-facto” standards. For example, you’re a “Java shop” because you use Java – not because it’s written down anywhere. In these types of environments, it’s very easy to break standards, because they don’t really exist. A project can implement in .NET if they feel like it, because there’s no piece of paper that anyone can point to that says “You must implement in Java”. This isn’t really standardization at all. It’s a gentleman’s agreement at best.
So the first step towards true Governance is to clearly document your organization’s standards on paper. You need to build up a body of written standards before you can begin holding people accountable to them. For us this process took about a year, so this is not an insignificant step. We found that we didn’t have as many “standards” as we thought we did. The process of writing them down really fleshed the standards out and highlighted the inadequacies of “de-facto standards”. We released standards updates quarterly, so the projects could start using them immediately. But we didn’t start really enforcing them right away because the body of standards wasn’t significant enough yet.
Step 2: Approve
After you document a body of standards, it needs to be formally approved by group with organizational authority – typically a Standards Working Group. Remember that as an Enterprise Architect, you have very little direct organizational authority. Most EA teams consist of only a few direct reports. The people who are bound to your standards don’t generally report to you. As such, you have no direct authority over their actions.
In order for your standards to carry weight, they need to be formally approved by an individual or group with direct reporting authority over the people who are bound to those standards. As an analogy, when Congress drafts a new set of laws, who do they send them to for formal approval? The President – head of the Executive Branch. In signing the bill into law, he or she is saying to the population “As head of the Executive Branch, I agree with this law and intend to enforce it.” Everyone knows the President has the authority to enforce the law.
Similarly, your Standards Working Group must be comprised of management with direct reporting authority that covers the folks who will be bound to the standards you’ve created. Typical membership includes the CIO/CTO, division managers, internal audit, and compliance officers.
Step 3: Communicate
A common excuse for non-compliance with standards is “I didn’t know about that standard, so I can’ t be held to it.” The solution to this problem is communication. Your first instinct might be to email or post to Sharepoint the standards and let it rest there. Delivery of standards updates in writing is absolutely critical, but it’s only a first step.
Your job as an EA to put a comprehensive communication plan together which includes both written and in-person communication. My recommendation? Post the standards to a web portal such as Sharepoint, email an announcement, and then follow up with an in-person training event – every single time you release standards.
The written communication can focus on the “What” – here’s what changed, see these new or modified sections. The in-person communication needs to focus on the “Why” and the “How”. Go into more detail – explain why you chose a specific standard, and how it will be implemented. Answer questions. Take feedback. You might even get some ideas for new standards.
Step 4: Review
OK, so now you’ve got an official set of standards, an approved by an authority group, and awareness across the organization. That doesn’t guarantee compliance. You need to get involved in design reviews of projects. These reviews need to happen BEFORE any construction begins. The best way to make this happen is to formalize your SDLC. Identify a “stage gate” between design and construction that specifies that a design review must take place.
Come up with a template for the high-value standards you want to evaluate in every single design review you participate in – security, data standards, transaction volume, etc. Have the project teams fill this template out in advance so you can focus in on key areas of the design.
Most importantly, choose the right people for your design team. A great place to start is to pick a representative from each of your architecture teams to represent their team. If you’ve got a good cross-section of EA teams, you should have representation from an application, data, infrastructure, and a business perspective. Other areas such as security are also helpful in a design review setting.
You need to also identify which projects go through a “full-on” design review, and which can go through a more streamlined process. Profile your projects – are they “enterprise class”, or are they a small inconsequential patch? The former certainly needs a full design review. The latter could probably be addressed by a self-certification to your standards working group. “I certify to the CIO and the Standards Working Group that my design complies with standards.” You don’t have the bandwidth to review every project. A self-certification process can help with this.
For now, your Design Reviews won’t really have any teeth to them. That’s OK. Use them as an opportunity to “encourage” and to “educate”. The phrases “we’d prefer” and “next time” are very useful at this stage. You’re building some best practices while establishing the Design Review as a critical part of the life-cycle.
Step 5: Enforce
Now you’ve reached the level of maturity where you can begin to enforce standards. Chances are you’ll encounter a project that simply refuses to abide by a critical standard. Now is the time to start enforcing using the authority of your standards working group.
The first step in enforcing standards is, ironically, to define an Exception Process. Face it – your EA standards aren’t perfect. In some situations they’re just not going to make any sense at all. You need to define an Exception Process so that projects have a “way out” when your standards just are not feasible. Typically this will involve the project filling out an Exception Request form and submitting it to your Standards Working Group.
If you agree with the Exception Request, encourage the Working Group to approve it. If you don’t agree, then it’s time for a little “Law & Order”. You as EA are the plaintiff, and the project is the defendant. Take your cases before your Standards Working Group and let them decide. They have the authority to either enforce the standards or approve the exception. This works quite well because it establishes that there is a defined way out of standards compliance in cases that just don’t make sense.
The important thing for you as an EA is to know when to accept some “technical debt” and side with the project team against your own standards. This will buy you enormous credibility when used appropriately because it shows that you understand how to balance the ideal of standards against the realities of the project world.
Step 6: There is No Step 6
Surprise! You’re already there. Once you’ve defined your Exceptions process, you have a functioning governance process.
As a recap, the steps along the Road to EA Governance are:
- Document your standards
- Communicate them to stakeholders
- Approve them through an authority group
- Review them with project teams
- Enforce them through a formal exception process
