The Practice

2008-2009 was a watershed for the EA Practice. Those that remain and thrive in the later days of the Great Recession are leaner, more business focused, delivering measurable value through strategy, governance and focus on critical interfaces between key enterprise components.

There are three trends that support this conclusion:

1. EA Practices are getting smaller and more focused on the business
2. There is more emphasis on strategy, process and governance and less on frameworks and tools
3. Managed services and outsourcing are driving architecture toward the lines, away from the boxes

For those who have read much of this blog, you know that a big theme is evolution of EA as a practice. In Evolution Was Bad For Neanderthals I stated that it's transform or die out. Thankfully, I think we are evolving.

EA Practices will continue to get smaller and be more focused on the business

The down turn in the economy has forced corporate America to carefully evaluate IT departments and ask, "Do I absolutely have to have this?" Let's face facts - it is hard to understand what we do; see Who's On First? and Nik's Malik's Understanding Enterprise Architecture. Businesses have retained EA teams that are perceived as being immediately valuable and jettisoned the rest.

While the signals of this are weak at present, it follows naturally that important skills for EAs are shifting toward the Business and Information layers in the Architecture domain stack because this is where a smaller EA teams can have the most impact on the company bottom line. If you are a young EA or desire to get into the profession, suggest developing the skills necessary to have a conversation with the business about process, data and technology in terms of cost, benefit, capability and risk then learn how to turn this information into simple boxes and lines that describe the future state.

There will be more emphasis on strategy, process and governance and less on frameworks and tools

In Welcome to Frameworkville and Digging to China, I state that frameworks and tools are on the path to architectural maturity but are not the path to it. My perspective comes from personal experience and talks with other EA teams - we all mistakenly thought that buying a tool or implementing a framework was the way to grow an EA capability.
Tools are complex, frameworks are abstract AND complex. Both require a recognition of the value of EA and a long term commitment to practice it a the highest levels. Considering the economically driven focus on survival, EA activities that provide immediate value to the business are better first steps towards maturity. Developing credibility as a strategic asset to the business is never a bad early step.

Effective EA teams, as they mature, will:

• Focus on providing easily consumed, strategic deliverables that executives can use to make decisions about the future of the business. Less "boil the ocean" analytic exercises with dubious short term value will be tolerated. Both tools and frameworks, while good, can distract teams from producing value.
• Define repeatable processes for producing EA deliverables then measure progress against these with a set of metrics. Continuously reporting progress against metrics is crucial to the survival of the EA team. It will also help drive priority decisions.
• Enforce architecture standards through governance, but consider principles and strategies as higher order standards. Maturing EA teams will develop "standards" in the form of principles and strategies first to supplement detailed technical specifications. Shortly, practices will realize that these strategic governance tools are making a bigger impact that the detailed technical ones.

Managed services and outsourcing will drive architecting the lines and not the boxes

Many IT organizations have turned to Managed Services as means to control IT costs. In my case both Infrastructure and Application Development was outsourced, introducing new challenges to architects seeking to control technology complexity and cost through standards.
Cost reduction by control of technology diversity is the primary theory of most Architecture Standards efforts. The challenge happens when bids and fees from Managed Services Providers are higher when using "standard" technology. When a provider bids $1M for a project using "standard" tools, but $0.5M using non-standard, how does the EA team react? What will the impact of the new technology on infrastructure management costs be? Architects must be prepared for that scenario.

Gartner has written extensively about middle-out architecture, or the idea that we can "architect the lines, not the boxes" extensively. This idea has a whole new meaning when considering the managed services operating model.

Middle-out architecture allows more flexibility to develop applications and manage infrastructure because standards focus on the lines (interfaces) between components of the architecture. The approach allows freedom to design the components (boxes) according to drivers of the moment (goals, costs, state of technology) while maintaining control over how things fit together.

By comparison, a large company could have hundreds of technologies, each having two or more standard versions, each having additional documentation. Managing all this can be time consuming. Given the trend toward smaller teams, the resources are probably not available to maintain the necessary standards at a satisfactory level.

Using a middle-out approach, the EA team focuses on protocols, data formats, service level agreements, and non-functional requirements between components of the architecture. Since there are far less meaningful interfaces between logical architecture components than there are potential technologies to manage, the effort is substantially less.

In the previous example, the "old school" of EA would probably opt for the more expensive option offered by their vendor, assuming that the "standard" technologies will be cheaper to operate in the long term. The middle-out EA team evaluates the options against against a smaller set of interface standards and selects the cheaper option based on its ability to operate seamlessly with other architecture components according to required service levels.

In Conclusion

Considering these trends, a new operating model for tomorrow's EA Practice emerges -
The team is small, maybe six to ten people for a fortune 500 company. It delivers repeatable value through simple governance processes, focusing on principles and conformance to strategy. It develops detailed standards only when required for critical interfaces between major architecture components. The Practice has evolved.