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.

In addition, an EA team cannot expect to obtain funding for strictly architectural projects like models, frameworks, or methodology. Nor can they wait for upper management support and exposure for those activities. It is very difficult to quantify value for these types of initiatives. They often meet with resistance from executives that have to sign off on the budget because many times these executives must justify the projects with positive customer response.

Next on the list is overzealous evangelism. You've all heard the evangelists touting lofty objectives, abstract benefits, and future value without a clear plan for progressing from where you are right now to the utopia of an established EA. Advocating "the corporate good" is a great way to get people jazzed about strategy, but without a clearly defined execution plan, it amounts to nothing. The other side of this coin is the "build it and they will come" mentality. It may work for a successful sports franchise to build a new stadium and attract a myriad of fans, but it will not work for the establishment of an EA.

Architecture teams will not gain allies by simply building models and providing pages of documentation to other teams. The consumers of this information have project timelines to meet, code to write, business meetings to attend, and so on. Without direct participation and buy-in from these "consuming" teams, the response is frequently apathy: Sure, just put it on the pile, and I'll read it when I get to it.

The Incremental (Results-Oriented) Approach
Incremental architecture is focused on results and value. The value of a common architecture is realized in the tactical application of strategic technologies. It is evolutionary progress instead of revolutionary progress. Architects need to implement architectural strategy through existing tactical projects. They should devote a substantial amount of their time to project teams that are well aligned with the business. This enables the expansion of architectural progress one solution, one service, and one person at a time.

The keys to success can be broken down into three elements: leadership, communication, and standardization. Incremental architecture is a concept that is valuable beyond corporate Information Services (IS) shops. For example, this article was created and finalized based on the principles of incremental architecture. It started with a vision and continued to evolve that vision internally at Calpine and externally at publication venues. It then progressed into a framework for the article's content, approach, and message standardization for relevance. Ultimately, the original vision was accomplished with tactical progress over time.

Leadership
Good architecture is a people challenge, not a technology challenge. Frameworks, methodology, and modeling are not productive in and of themselves—architecture must be action-oriented. The focus must be on creating value, changing behavior, processes, and executing the larger strategy.

People want to have a clear picture and roadmap—a plan that has a defined path of execution. Establishing a clearly defined and reproducible System Development Life Cycle (SDLC) process is a key step in the roadmap. This process provides our architecture and design team with important collaboration touch points among the majority of IS initiatives in the portfolio. The SDLC gives the team an opportunity to review and revise an individual project plan, ensuring that it satisfies long-term and strategic goals. The SDLC also involves the team in the day-to-day operational activities of the business—no more ivory tower!

Over 50 percent of architects' time should be allocated to project-based work. This will allow architects to share the overall corporate vision, interact with multiple team members (business analysts, developers, and so on), and prove their worth on tactical efforts. Many strategic objectives as well as various EA initiatives (modeling, framework development, pattern documentation, and so on) can be achieved incrementally by showing that they apply to a particular project.

For example, architecture team involvement in projects with various reporting needs across numerous business units call for a near-term, common approach to reporting. On the architectural vision side, enterprise reporting and other business intelligence (BI) strategies align with strategic business goals. The tactical project requirements are a perfect match. They drive momentum for increasing reporting and BI maturity for competitive advantage, while also meeting individual project goals.

Communication
The ability to build relationships and establish alliances across the organization should not be understated. Great care and effort must be put forth to reach individuals outside the typical technological arena of an architecture team. To be successful at increasing EA awareness, you have to find creative ways to streamline the communication process.

There are a few main factors for successful communication in the architectural arena that go beyond the usual communication theory course. Remembering these principles will help you make your point:

• Relevance.
• Practicality.
• Addressing key stakeholders.
• Delivering the right message.
• Collaboration.
• Trial and error.

Information overload is commonplace within today's workforce. Two creative ways that Calpine has had success in communicating vision and strategies are through the communication mediums we call "whiteboards" and "roundtables." Our whiteboards are short video-based presentations that explain specific areas of technology, standards, projects, or vision. Podcasting is becoming increasingly popular, and whiteboard presentations are a spin on the podcast concept.

It is much easier for someone to digest information from a video presentation than it is to pore over pages of documentation. It is also more efficient for the architect to communicate thoughts in this medium than to write them down on paper. You can take the whiteboard concept a step further if you require certain individuals to watch the video by incorporating it into a learning management system's courseware. After watching the video, these individuals are more likely to be successful at their jobs.

Also, you should never be above marketing your team's agenda and goals. A creative example of this is placing a one-minute, team marketing section at the beginning of communication videos, similar to the way online news Web sites create their videos. Remember, in a whiteboard communication strategy, communication is one-way, not collaborative. Allow for necessary collaboration beforehand on any initiative described or defined in a whiteboard, and describe the parties involved in helping the work progress.

Roundtables are gatherings of key stakeholders in a particular technology or project. They can be either technology-focused with a goal of extracting project ideas or project-focused with a goal of extracting technology implementation ideas. Numerous positive things come out of roundtables. Innovation is sparked by encouraging moderated communication about a topic between individuals who don't normally talk to each other. Architectural strategies, new project ideas, system improvements, and especially cross-team communication are other byproducts.

These events don't take much time, and the return on investment for time spent is enormous. These are true collaborative gatherings. Individual idea exchange and contribution should be encouraged and be part of the rules that are established up front. Collaborative decisions do not make the IS community feel that they are receiving directions from above. Instead, they engage creative IT talent in developing the resulting strategies.

An architect has an exceptionally challenging job. He or she must align with the business and understand objectives to have a clear grounding in the conceptual underpinnings of many different technologies. Fundamentally, an architect must be a leader and communicator who is capable of bridging the gap between technologies, customers, and business goals by turning strategy into tactical reality.

The incremental architecture approach adds additional value to individual projects because they now are aligned with strategic technical goals instead of purely tactical goals for the business. Leadership and communication are marked as cornerstone components for the success of the incremental architecture approach.

About the Authors
Chad Riland is the Manager of Architecture and Design and Josh Paterson is an Application Architect for Calpine Corporation. Calpine Corporation was recently ranked by Information Week as the most innovative users of information technology among energy and utility companies and fifth across all categories of companies. You can e-mail Chad at chadriland@gmail.com and Josh at Josh_Paterson@hotmail.com.