Your company's software process should be reflected in every level of its structure and culture.
Terms such as “component-based architecture” and “distributed architecture” have sold senior management more than once on new technology, but architecture is more than just a marketing buzzword. Software’s architecture describes the elements (objects, components, frameworks) from which the software is built, the interactions among those elements, the patterns that guide their composition, and the constraints on those patterns. Knowing what architecture is, however, isn’t enough. You must also understand the process to define and evolve your architecture, organize your architecture team, build an architectural culture within your organization, and choose appropriate tools to support your architectural efforts. Figure 1 shows the symbiotic relationship between architecture, process, tools, and organizational culture. Any change to one element will eventually result in changes to another.
| Figure 1 |
 |
Last month’s column described the architectural modeling process, as depicted in Figure 2, and several key concepts of architectural modeling. First, you need both an organization-level and a project-level architecture. Second, there are two flavors of architecture, domain and technical, at each level. Third, your enterprise model defines your organization’s high-level requirements and should drive the development of your organization-level architecture. Fourth, your organization-level architecture and project requirements are the starting point for your project-level architecture. And, fifth, your project-level architecture drives change to your organization-level architecture.
| Figure 2 |
 |
What do you do if senior management doesn’t see things this way? Managers commonly don’t feel the need to invest in architecture, either because they don’t have the resources or they believe technology changes too quickly to make the investment worthwhile. I believe this is short-sighted. If you have the resources to build software “the wrong way” without architecture, then surely you have the resources to do it the right way.
Do changing technologies really matter? One thing that the Year 2000 crisis has shown is that the systems you build today will be in production 20, 30, maybe even 40 years from now. It doesn’t matter whether the technology you use today will change tomorrow. You’ll still be stuck with it—and if you don’t use that technology the best way possible, you will have another maintenance nightmare on your hands.
A second common mistake is investing only in project-level architecture, which quickly leads to “stovepipe” systems that don’t integrate easily and achieve little, if any, reuse. Project-level architecture is a good start, but not a complete solution. To resolve this problem, you must identify the commonality between systems, and start with technical architecture. It is easy to justify developing or purchasing a common approach to security access control, a shared persistence layer, or a common user interface framework. When management sees many similarities between the applications being developed within your organization, it’s easy to convince them to invest in organization-wide architectural efforts. Although you may start with technical architecture, never forget that you also need a domain architecture. You should be prepared to point out similarities in your domain once you have had success on the technical side.
Another common mistake is investing in organization-level architecture but not project-level architecture. Typically, these project teams don’t take advantage of their organizations’ architecture teams, due to excessive deadline pressure. The architecture team members are often frustrated because their good work is not being used. This problem often stems from an “ivory tower” approach to architecture, in which the brightest and best are sent off to develop an architecture and then asked to bring it back to the programming masses on the project teams. This may be interesting for the people in the ivory tower, but it’s not very palatable for the masses.
To address this problem, you must understand what role architects should play within your organization and then ensure that they actually fulfill that role. Architects help define and guide your organizational and project architectures, acting as leaders and key decision makers at some times and as mentors or consultants to your project team at other times. Ideally, architects are responsible both to your organization’s senior management and to the analysts and designers of each project team. Architects should be actively involved in establishing your business and technical strategy, as well as your organization’s technical direction. The most effective organizations include software experts whenever they negotiate a major contract or define a major organizational strategy. Architects guide technology and architectural decisions, and provide key input into your organization’s development guidelines, policies, and processes. In short, architects should be key players within your organization.
When building your organization’s architecture team, you must first find good people to be on it. A common joke in the software industry is that you merely need to ask a group of designers to cross a puddle, and then take those who don’t get their feet wet because they are the ones who can walk on water. In case this approach doesn’t work for you, the best architects are people who not only understand the details of how to build something but know where and when to dive into those details. Architects are abstract thinkers with good technical and communication skills, the humility to understand that they don’t know everything, and the confidence to make important decisions when they are needed most. Architects can mentor the people that they work with and be mentored themselves.
It isn’t enough to have good people on your team; you must also organize them effectively. Architecture teams should be small, ideally four to six people, and must have a single leader. This person typically has the title of “lead architect” or “chief architect” and is responsible to your senior management for developing and supporting the architecture. Many architecture teams flounder when they try to take a democratic approach to setting architecture—a problem also known as architecture by committee—quickly devolving into endless arguments or producing bloated architectures that contain far more features than necessary.
Your organization’s architects will act as consultants to your project teams, either working with them as a full-time member or as a part-time resource. When architects work with a project team full time, they quickly lose touch with the other architects within your organization, falling behind on the latest developments. It also makes it difficult to share the project information that they learn with the rest of the architecture team, which in turn, makes it difficult to get your organization-level architecture updated appropriately. The one advantage to working full time on a project is that it helps the project move forward.
For this architectural approach to work, your organization must accept that projects should be architecture-driven. Developers must also accept that their job isn’t to reinvent the wheel, even when they think they can make it better, but rather use the wheels that the architecture team supplies to build a new automobile. Just as architects need humility, so do your project’s development staff. As always, the willingness to work toward a common goal is an important cultural value for your organization.
Project teams must develop both a project-level domain architecture model and a technical architecture model, showing how your software uses the organization-level architectures and indicating any proposed changes. You need at least one person in the role of project architect—and, depending on the size of your project, you may need several people. Project architects work with your organization’s architects (in small companies this may be the same person) to both exploit the existing architecture and develop a new one for your project. The project architect then acts as a consultant to the developers on your team, sharing and evolving the architecture with them as needed.
To clarify Figure 2, part of architectural modeling is analyzing existing systems to understand both the business environment that those systems support and the technical environment in which your system must operate. Ideally, this effort should be done at an organizational level. One aspect of your technical architecture should be a “legacy deployment model” that shows the existing systems within your organization. If you do not have such a model (few organizations do), then your project team needs to identify the legacy systems and their interfaces. These interfaces may not even exist, in which case your team may be given the access rights to directly read from and update the data sources of the legacy systems (yikes!). More likely, there will be interfaces in the form of stored procedures, an application programming interface, or even a full-fledged object-oriented or component interface that you will need to understand. Beware of strangers bearing gifts! I have seen several architecture teams led astray by their data/system analysis efforts—don’t let these interfaces overly influence your architecture. Do not let poor design decisions made years ago propagate into your new software.
Modeling Tools
To be effective at architectural modeling, a modeling tool must support both organization-level and project-level models with full traceability between them; support a wide range of models, such as the UML, persistence models, business-process models; and support version control and configuration management of your models. Architectural modeling is challenging for tool vendors. Typically, tools are either targeted at project-level modeling or enterprise architectural modeling, but not both at once. Few tools support multi-team development; in my experience, checking models in and out of a repository simply doesn’t scale, nor do many tools support full traceability (or any traceability, for that matter).
Architecture is a complex endeavor, but it’s key to successful software development. You need a proven and mature process for architectural modeling, an organization structure that reflects that process, a culture willing to take an architectural approach, and tools that support the goals that you are trying to accomplish.
