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:

1. Document your standards
2. Communicate them to stakeholders
3. Approve them through an authority group
4. Review them with project teams
5. Enforce them through a formal exception process

What is “Getting Things Done”?

Getting Things Done is a time management system invented and popularized by David Allen.  Here is the basic premise of the system, according to Wikipedia:

GTD rests on the principle that a person needs to move tasks out of the mind by recording them externally. That way, the mind is freed from the job of remembering everything that needs to be done, and can concentrate on actually performing those tasks.

The trick with Getting Things done is that the system is designed to be lightweight enough to capture items quickly and easily as they come up.  You don’t need to be sitting at a computer, have a PDA, or have any expensive accessories to make the system work.

So How Does “GTD” Work?

The basic idea with GTD is that any time a new task shows up on your plate, be it from an email, something that popped into your mind, or a phone call – you write it down.  Most people use a small notepad to capture these short “todos”.  Once you’ve written the task down, it’s transfered out of your short-term memory and into reliable temporary storage.  Notepads don’t forget.

Later, when you’re back at your desk, you empty all of the todos from your notepad into your “inbox”.  That way you’re not carrying them around with you any more.  They are safe at your desk, waiting for you to organize them when you have some time.

When you have a few minutes to think, you sit down at your desk and work on your inbox.  You’re going to priorize and sort your todos so that they are actionable.  At this point, GTD’s concept of “43 folders” comes into play.  At your desk, you’ll have a set of 43 paper folders – 12 for the months of the year, and 31 for the days of the month.  As you go through the todos in your inbox, you simply choose one of those 43 folders to drop the item into.  If you can get to your “Schedule Business Architecture meeting” task on the 15th of this month, you drop it into the “15″ folder.  If you need to “Upgrade the SOA Repository Server” in January when a new patch is release, you drop that note into the “January” folder.  What you’re doing is creating reminders to your future self.

You see how the whole system revolves around moving “todos” out of unreliable storage (your memory) into reliable storage (your inbox), and finally into organized storage (your 43 folders).  The idea is that your mind’s full mental capacity is freed up to execute tasks because this simple system is managing the timing and organization of those tasks.

There are more subtleties to the system, such as managing tasks around projects and delegating to others, but this essentially describes how GTD works.

Why Does This Matter to Me as an EA?

My previous article discusses why a good time management system is so important to an Enterprise Architect.  Because of the broad scope of EA’s responsibility, I’m sure you’re familiar with the constant barrage of requests for your time.  You need a good system to manage all of these requests to ensure that you’re delivering value to your stakeholders.  In my experience, GTD is an extremely effective tool for this purpose.

Where Do I Get More Information?

Read David Allen’s book, which is also available as an audio book.

Do I Really Have to Carry a Notepad Around?

No.  I’ve implemented GTD fully electronically, using Outlook and Blackberry.  I’ll discuss how I did it in a future article.

What is Time Management?

Wikipedia’s definition of Time Management:

Time management refers to a range of skills, tools, and techniques used to manage time when accomplishing specific tasks, projects and goals.

Why is Time Management Important to an EA?

Intangible Nature of Architecture

Architecture is by its nature an intangible.  It’s easy to get lost in the intricacies of research and decision-making without delivering concrete results.  Architecture doesn’t exist within the framework of a project planning framework as your typical project does.

A time management system provides this necessary structure to keep an abstract art delivering concrete value on a consistent basis

Constant Distractions

EA, perhaps more so than any other area of IT, is subject to constant interruption.  Right in the middle of authoring your strategy document, your audit department calls with a question.  Then you get back to writing your strategy document and you’re invited to a review meeting.  Afterwards, you’re pulled into a discussion about a production problem, and then it’s time to go home.  Your strategy document will be lucky if you remember it in the morning.

A time management system keeps all of your thoughts and tasks in one place where they are waiting for you when you return to the office.

Multiple Parallel Tracks

Because of EA’s broad reach, it’s common to have multiple tasks moving forward in parallel.  Your Business Architecture team is exploring business process modeling while your Application Architecture team is researching web services and cross site scripting.  Meantime your Information Architecture team is working on data standards and your Technology Architecture team is performing an infrastructure inventory.  All of these parallel items have tasks that you need to track.

An effective Time Management System allows you to track tasks for parallel activities without getting overwhelmed or bogged down in the details.

Future Needs

As an EA, you’ll constantly identify items that need to be addressed “someday” or “in a couple of months”.  These can easily fall off the radar as you pursue more pressing matters today.

A Time Management System will help you capture those important items for future consideration and come back to them when the time is right.

Summary

These are just a few of the key drivers that make time management a necessity for the effective Enterprise Architect.   In my next installment, we’ll dive into a popular Time Management System called Getting Things Done, and how it can help you in your EA practice.