email article printer friendly

Incremental Architecture: Principles for the Real World
Learn how you can establish meaningful enterprise architecture, cut costs, and deliver solutions more rapidly.
by Chad Riland and Josh Paterson

February 14, 2006

How can enterprise architect teams successfully establish meaningful enterprise architecture while meeting management demands to cut costs and deliver solutions more rapidly?

As solution architects, we are continuously faced with the business drivers to cut costs, deliver solutions more rapidly, and respond to customer needs with more flexibility. In light of this fact, we must develop a practical, focused strategy that will allow us to meet goals toward furthering enterprise architecture (EA) initiatives (i.e., business alignment, standardization, reuse of existing IT assets, and sharing common system development methods), as well as meeting the enduring demands of business units and upper management.

The ultimate goal is to design more agile and responsive enterprise systems that provide the value our business partners demand, in addition to the integration flexibility for which architects and developers have been striving. To reach this goal, we must avoid two common pitfalls of EA endeavors: not showing clear business value and being perceived by the development organization as overhead or bureaucracy.

We can remedy those concerns and achieve this vision by applying standards and practices incrementally over time. Show value project by project and expand the EA influence to one solution, one service, and one person at a time. In a rapidly changing business environment of tactical decision making, it is often easier to justify small EA efforts that show immediate value than to get buy-in and funding for large-scale EA projects that many perceive as the "ivory tower." Project-based initiatives can be used as the starting point for any company's long term EA vision, and form the basis for reusable standards and best practices.

Why Enterprise Architectures Fail
Many attempted EAs fail because they wait to resolve too many details before setting a specific direction. They try to take the Big Bang approach, or assume that there will be less risk and better long-term results if all of the details are gathered up front. However, this doesn't work in today's tactically driven enterprise, where the time and resources needed for an all-encompassing approach are difficult to obtain. In many cases, an immediate decision is better. Otherwise, there may be no decision at all.

In fact, an architect must frequently present a solution prior to knowing all of the details of the problem. This formula is often difficult for technical or analytical thinkers to follow. The career path of an architect is typically one where he or she has moved up through the technical ranks—first developing some basic software systems; graduating to more complex systems where he or she had to understand and apply design methodologies; and after showing successful results, moving into an architecture position. This progression can perpetuate the view that EA is all about technology (i.e., technical expertise, standards, and picking the best technologies). If this attitude is left unchecked, it can result in disputes within different factions of the organization over specific technologies.

Another issue may reside in individuals within the organization who come from a strictly technology background because individuals with this type of background tend to lack leadership and management skills. These individuals may attempt to control others with their rank and authority; or, on the other hand, they may not attempt to manage at all and simply continue to focus on technology. They may attempt to enforce rules without getting agreement from the development team and business sponsors. In these cases, others will hesitate to include architects on project teams.

EA failure also has to do with how the organization perceives the architecture team. After half a decade in the '90s of the double-digit IT budget expansion, corporate IT growth has dramatically slowed down. IT is being asked to deliver the same amount of new capabilities with decreasing budgets. If an EA team (and IT in general) is not conscientious about the influence of budget constraints on their environment, and not developing new ways to thrive in that environment, a perception will evolve in the business units that EA teams may not meet needs.