Agile Architecture at Canaxia

Is it possible for Canaxia to take an agile approach to its enterprise architecture efforts? Canaxia's situation certainly isn't ideal:

• It is a large, multinational organization, which implies that the business rules, culture, and laws are likely to be very different in each country in which it conducts its business.

• It needs to support a wide range of business applications (finance, production, human resources, and so on), some of which have very little to do with others.

• There may not be a perceived need to change. Because the current architecture has remained relatively unchanged for two decades, chances are very good that many people within IT are perfectly happy with the status quo.

Although any one of these issues would provide Canaxia with a good excuse not to try to be agile, that doesn't mean it should take it. Too many IT professionals like to use the "Technique XYZ is fine for everyone else, but we're unique" excuse to not try new approaches. The reality is that every organization is unique, including Canaxia. Yes, they have some problems. The fact that they are a large multinational organization is likely the largest problem to overcome because it introduces several barriers to communication, but that's going to be an issue whether they take an agile approach or not.

Canaxia's first step should be to form a core architecture team (CAT) that is responsible for developing, supporting, and evolving the enterprise architecture. This CAT team should include people who represent the overall IT constituency. There should be one person, although two are better, from each regional office as well as headquarters. Furthermore, the team must represent the various types of applications within Canaxia, and the easiest way to do that is simply to have a representative from each major project on the team. At the same time, Canaxia should strive to keep the size of the team under ten people, ideally no more than five to seven people, because the larger the team gets the more unwieldy it will become.

The CAT is responsible for defining the initial architecture, getting it just good enough so that Canaxia's development teams have some guidance regarding the enterprise architecture. As depicted in Figure 7-2, the CAT would define the initial enterprise architectural vision and models, a process that would likely take several days or even a week or two. Any longer and the CAT will be at risk of developing architectural models that don't actually reflect something that will work in practice. Remember, your models need to be just good enough, not perfect. The key idea is that your enterprise architecture model(s) start out small and are fleshed out over time based on the feedback you receive from both the business community and from project teams.

Figure 7-2. An incremental and iterative approach to architecture.

The CAT would work with Canaxia business stakeholders while they are modeling the architecture and this isn't simply an intellectual task for the team. An enterprise architecture must reflect the actual needs of the business. Therefore, part of your architecture efforts must be to identify architecture-level requirements. Without requirements you are effectively "hacking in the large," a recipe for disaster. Therefore, the CAT should follow the AM practice of Active Stakeholder Participation and work closely with business stakeholders, including Canaxia senior executives and other subject matter experts (SMEs). Agile enterprise architects will often find themselves in the position of leader, facilitating senior executives in the identification and evolution of the vision for the system.

The CAT must communicate its models to the larger business stakeholder community. Canaxia chose to enlist the stakeholders who were involved with the modeling efforts for this purpose. The stakeholders must communicate the models to the business community, give several interactive presentations, and publish summary information specifically targeted at business professionals. Their efforts are critical to the success of the enterprise architecture efforts within Canaxia. The business stakeholders will be actively involved in the development and use of business systems. Therefore, they need to understand the overall vision and direction of the organization. A side benefit of this effort is that they'll provide valuable feedback about your architecture: Sometimes a simple question from someone in your presentation audience can identify a serious weakness in your approach.

Figure 7-2 depicts another important activity, which is for CAT members to actively work with developers on project teams to communicate the enterprise architecture. This will provide the technical feedback required to update and evolve the architecture models and documents over time. Agile enterprise architects spend their time modeling and documenting the architecture, communicating it to business stakeholders, and working with developers to both ensure that the enterprise architecture reflects the actual realities faced by the team and that it is implemented in practice. In this respect, the architects find themselves in the role of coach, helping to transition skills and knowledge to customers, business stakeholders, and developers.

When Canaxia organized the CAT, it decided to gather the team at Canaxia's world headquarters in the United States for a two-week, initial modeling effort. It also chose to fly in several business experts from each region to ensure adequate representation and to send out the message that Canaxia was serious about the effort.

Immediately following this initial meeting, the team kept in contact via email, a shared documentation repository, impromptu phone calls, and video conference sessions. At first, regular video conference sessions were held each week to discuss common architectural issues, but once the team got used to working together in an impromptu fashion, these meetings were held every second week and eventually once a month.

Once a quarter, the team got together physically for one week at one of the five regional headquarters. At least one person from each region was required to attend, and often they would bring one or two senior developers with them from project teams to help share information with the enterprise architecture team. During the week that the architecture meetings were held, the architects were made available to local development teams, as well as local business stakeholders, to provide advice to the teams as well as to learn from them. When CAT team members were at their home locations, they were co-located with project teams, working as active team members.

Canaxia decided to take a flexible approach with tools. The CAT decided that all documentation would be written as HTML files using simple picture formats (.jpg and .gif) but that members could use any tools that they liked. Most members chose to work with simple tools such as an HTML editor and whiteboard; they took digital snapshots of their diagrams and then cleaned them up using WhiteboardPhoto (www.pixid.com). A few members chose to create presentation-quality diagrams using Visio (www.microsoft.com), which was already a corporate standard. Although Canaxia owned several licenses for sophisticated enterprise modeling tools and was willing to purchase licenses for other tools as needed, the architects decided to wait until they needed the features of the tools before using them and they never did.