Welcome to Frameworkville

Welcome to Frameworkville, the place every Enterprise Architect wants to live! As you can imagine, it's is growing by leaps and bounds. The south subdivision, Zachman Heights, is charming with its venerable View trees lining neat streets arranged in a perfect matrix. The fastest growing suburb is TOGAF Landing; lots of people are moving there to live near the orchard of Content.

So there you are, cup of Kool Aid in hand, having just moved into this blissful town with the rest of your EA family. Suddenly your cubie buddy’s phone rings. He hurries quickly to the big bosses’ office and return in minutes. Head hanging low, he begins to clean out his desk. Guess he won’t be moving in to Frameworkville with the rest of the team. What! Mary, behind you, is also on the long walk back from the boss. What’s going on? The three of you just went to training and where going to spend the next month populating the the enterprise continuum with architecture artifacts according to the content metamodel.

Reality check - your team just went through a down sizing; where economic reality meets the ideals of an Architecture Framework. That reality often dictates that EA stay focused on delivering immediate value rather than ramping up to a framework that dictates abstract deliverables created through arcane processes. .

In Digging to China - Just Because You Can Doesn’t Mean You Should, I suggest that tools are not the way to drive EA maturity. I make the same argument here. Please do not get me wrong, I’m a big fan of Architecture Frameworks, when properly introduced into organizations that are sufficiently mature and operate at appropriate scale. I occasionally speak with EAs from other organizations that are investigating or have adopted a Framework as a way to drive architectural maturity. My thought - been there, done that, doesn’t work!

Like tools, Frameworks are a significant step in the evolution of an EA practice and every team should strive to have one. I’ll even go further to argue that without a framework, deliverables will have consistency and quality issues. That said, do not think that a framework IS the roadmap to maturity. Here is why -

We are in the business of communication. At the end of the day, if EA work products are not used to drive decision making, what good are they? An analyst colleague made a keen observation a while back - EAs do not do EA. EAs lead the organization in the practice of EA.  

If EA process cannot be simply explained, and if deliverables are not immediately useful, we will soon become extinct (see Evolution Was Bad for Neanderthals) because we do not contribute value. Unfortunately, ease of understanding is not a characteristics EA frameworks. Anybody who has attempted to absorb one can witness to this. Do I hear and Amen?

Having a framework is a milestone along the EA maturity path; but please consider a couple of things before you convincing the CIO that one is required now:

• At what scale do you operate? For example, my current team is about 20 architects at a $7B company with 7000 employees. We get along reasonably well without a formal framework. Frameworks become more useful at larger scales because they enforce  discipline that can be difficult to attain otherwise. Federated architecture teams benefit even more because frameworks keep geographically diverse EAs working consistently.
• How mature is your IT shop? Since EA is about communicating; how easily will IT executive’s “get” the framework and its deliverables? Will the CIO tolerate “two steps back to take three forward”? Implementing a framework can divert focus from immediate priorities while the team gets trained, begins to execute and starts speaking in the new lexicon (which may sound like tongues to the rest of IT - metamodels, continuums, views, etc.) 
• How mature and IT-oriented is your business? A focus of any framework effort should be the production of deliverables that guide the business towards better investments in technology. If you have to spend time decoding framework deliverables into pretty pictures for the business, the framework return on investment is eroded. If your business partners think architecture is just ‘some IT mumbo jumbo’ and just want  solutions delivered according to their orders, rethink how ready you are for an EA framework. Sucessful framework implementations bring business and IT together.

If you are part of a young EA team, what should you do? Here are some ideas that I will close with -

• Do adopt IEEE 1471, this is a very simple set of concepts, a meta-framework if you will, that other frameworks such as TOGAF are built upon. The specification defines ideas like stakeholders, their concerns and how architecture views address the concerns. Spending time figuring these things out and producing products that address stakeholder concerns is a quick way to mature and demonstrate value.
• Do define a set of measurements that establish how the EA will make a difference. Execute on making that difference an then come back with the data.
• Do create an EA Charter that defines why EA exists and what organizational expectations are. Incorporate the metrics defined above. Use this as your organizational framework for executing EA.
• Do get closer to your business. EA is about business, not technology - at the end of the day, if the EA team’s work has not made a difference to the business, then it has missed out (See Real EAS Don’t Where Ties.)
• Do get familar with EA frameworks and cherry pick good ideas that your organization can easily adopt and that generate quick value. There's lots of good stuff in framework specifications if you spend the time absorbing the key ideas.

At the beginning of the journey is all about building credibility, culture and synergy. Once the business and the CIO are coming to EA because the team that can identify opportunities and clear obstacles, then you are ready to say, “if you think this is good, wait till you see what I can do with a Framework!”.