Information technology is a critical element for many organizations, whether their IT supports internal systems or the creation of software products that represent their core business. In both cases, software is an essential element of their success, and these organizations naturally seek an environment for developing high-quality software in a timely, cost-efficient manner.
Such environments present challenges; and, interestingly, these challenges are similar to those of the systems they support. For example, development environments have to deliver against the required functionality and properties (such as performance and usability), often have to coexist with legacy systems (such as, in the case of a development environment, existing methods and tools), and have to acknowledge other constraints (such as the distributed nature of development teams, and existing skills and infrastructure).
All in all, creating a well-oiled development environment that accelerates, rather than hinders, project performance is a science unto itself. This is why IBM® Rational® has spent many years specifically developing a services capability that understands the challenges faced by organizations that 1) want to improve developer productivity, and 2) regard their development organization as a strategic differentiator, rather than simply a cost center.
Our experience has led the Rational team to define a role within the software development lifecycle called the "development environment architect." In October 2007, one hundred of Rational's most experienced development environment architects from across the globe gathered together in the first conference dedicated to this role to share their experiences. This article is a result of that conference and the discussions that took place.
As you read the concepts presented here, you may well question whether the development environment architect should be a role itself, or whether the individual or team who normally functions in the software or systems architect role should simply add consideration of the development environment to their list of architectural concerns. I believe that both propositions are valid. Furthermore, whenever the role of the "architect" is discussed, it is always qualified with the domain under consideration; thus we speak of a "building architect," "software architect," "systems architect," "enterprise architect," etc. The development environment is simply one of these domains, and one that is not traditionally a concern for the "software architect" role. I therefore believe that the "development environment architect" role is one that hasn't been emphasized before -- hence this article.
This article has several audiences and objectives. It is relevant to organizations undertaking an improvement to their development environment and who need to understand the value of a development environment architect to help guide their initiative. It is also relevant to those who are responsible for the technical content of the development environment -- i.e., development environment architects -- because this article introduces this responsibility as a role not previously defined. Finally, this article may supplement material contained within a development environment, in helping communicate its content, the role of its architect, and the benefits of having such a role in place.
I will discuss the following concepts, in order:
Definition of a development environment. I will emphasize that such an environment is more than methods and tools. This definition sets the scene for the remaining sections, by providing a framework for thinking about all aspects of a development environment.
Architecture of a development environment. This should be relevant to anyone unfamiliar with the concept of architecture, and how it applies to a development environment.
Characteristics of the development environment architect. This is useful for those wanting to undertake such a role, or those wanting to find suitable candidates for fulfilling such a role.
Process of architecting a development environment. This is useful for those wanting to better understand the characteristics of the tasks performed by the development environment architect.
Benefits of architecting a development environment. This section is particularly useful to those needing to convey the value of the role of the development environment architect or those considering such a role within their organization.
What is a development environment?
The IBM Rational organization considers a development environment to be composed of the following:
- Tools (for automating aspects of the method)
- Enablement (in methods and tools)
- Infrastructure (to support methods, tools and enablement)
- Organization (to use and support methods, tools, enablement and infrastructure)
These elements are shown in Figure 1, and they are explained in detail below.
Figure 1: Elements of a development environment
A key element of any development environment is the method that is followed, whether formally or informally, by practitioners. A method defines project roles, tasks, work products, and processes. It is also underpinned by guidelines, standards, templates, and examples that can be applied on a project.
Development tooling automates aspects of the method being followed. For example, we may use a tool for storing and managing requirements on the project, or use a tool for visually modeling our architectures and designs, or use particular tools for testing our software, and so on.
Enablement (training and mentoring) of practitioners in the use of the development environment contributes to its successful adoption. Therefore, an aspect of a development environment is the definition and creation of training and mentoring materials that can be applied. The enablement itself is focused on the use of the method and tools within the environment.
Method, tools, and enablement are supported by some infrastructure (hardware and software). For example, we may want to Web-enable the method, then deploy it on the company intranet, which would require a Web server and some hardware on which to run it. Development tools are often run on practitioner workstations with an appropriate specification (in terms of CPU, memory, and disk). Training materials may be made available via several mechanisms, over and above classroom training -- for example, Web-based training that would require the presence of a Web server and associated hardware.
The right organization is critical to support the use of a development environment. This may include providing specialists in certain aspects of the environment (such as method experts, tool specialists, trainers, and mentors), personnel to administer and support the environment, and personnel to augment the existing set of skills available through the company Help Desk.
In addition to the environment itself, which requires people, there is clearly a need to create (develop) the development environment, which also requires people (including the development environment architect). This can cause some confusion! In Figure 1, and throughout this article, the method, tools, enablement, infrastructure, organization, and adoption are all considered to be part of the environment itself.
In addition to the elements listed thus far, a development environment architect is concerned with the adoption of the environment. This is more than simply acquiring the relevant hardware and software, installing and configuring the environment, and training and mentoring end users. Adoption is equally concerned with the migration of existing assets (such as work products residing in a now-legacy toolset) and the collection of measurements that allow the development environment to be assessed against desired results. In addition, the architect may need to consider mechanisms for allowing the customization of each of the elements of the development environment in order to address the particular needs of a given business unit, program, or project.
The most important aspect of adoption of a development environment, however, is that it represents a change in the organization. Since it is natural for individuals to resist change, there are several frameworks available that can help effect an organizational change, such as that described by John P. Kotter.1
In addition, there are elements that affect various aspects of method, tools, enablement, infrastructure, organization, and adoption. These additional elements cut across these areas described above, and they represent functionality, qualities, or constraints. The functionality provided by a development environment represents a particular software engineering discipline, such as testing. A quality represents a property exhibited by the development environment, such as the ability for the development environment to scale to support different numbers of concurrent users. A constraint represents a restriction on the options available for implementing the development environment, such as the need to accommodate a particular operating system. These elements are discussed in more detail below.
Functionality that represents a software engineering discipline requires consideration of all areas described above. For example, a testing discipline is supported by a development environment that contains:
- Method elements that are related to testing (such as testing roles, testing work products, and testing tasks)
- Tools that automate aspects of the testing method
- Enablement in the form of testing-related training and mentoring materials
- Infrastructure in the form of hardware and software to support the testing method, tools and enablement
- An organization with appropriate testing skills
- Adoption of the testing capability
This thinking can be applied to all disciplines that are part of the development environment, such as business modeling, requirements, architecture and design, implementation (coding), deployment, configuration management, change management, project management, and so on.
A quality that the development environment should exhibit also requires consideration of all areas. For example, a scalability quality (the ability to support a varying number of concurrent users) may be accommodated through a development environment that contains:
- Method elements that can be customized to fit the size of a project
- Tools that can be configured to support a configurable method
- Enablement mechanisms that provide appropriate levels of training and mentoring for different sizes of project
- Infrastructure that can scale to support the anticipated number of concurrent users
- An organization that ensures that appropriate levels of correctly-skilled resources are available to ensure successful project execution
- Adoption of the environment using appropriate mechanisms
A constraint that the development environment should accommodate may also require consideration of all areas. For example, the need to migrate from an existing environment may be accommodated through a development environment that contains:
- Method that acknowledges practices from any existing method and incorporating them in a new method
- Tools that support migration of work products from a deprecated toolset
- Enablement materials that acknowledge current skills and are customized accordingly
- Infrastructure that maximizes reuse of an existing infrastructure (such as reusing existing hardware and software licenses where possible)
- An organization that accommodates a smooth transition from an "as-is" state to the "to-be" state
- Adoption mechanisms that acknowledge the migration to be performed
Another important constraint associated with the implementation of a development environment is return on investment (ROI) which, again, requires us to think about each area in turn. In order for such an initiative to succeed it must deliver positive results that are in line with the business case for the initiative. Each area of a development environment influences the ROI in terms of both cost and benefit; and adoption of a development environment, in particular, may need to place some focus on measuring the results achieved through the use of the environment.
What is the architecture of a development environment?
Having defined the elements that make up a development environment, what is it that the development environment architect focuses on? The area of software and systems development can help answer this question.
As we shall see in this section, and later sections, the role of the development environment architect has much in common with other types of architects. The remaining sections of this article apply, to a large extent, to any type of architect, whether this is a development environment architect, a software architect, a systems architect, and so on. In fact, much of this material is based on a series of articles that I wrote that describes the role of the software architect.2 However, the relevant material has been included in this article in order to provide a more complete overview of the role of the development environment architect. The material has also been condensed and made more specific to the role of the development environment architect, where relevant.
There is no shortage of definitions when it comes to "architecture"; there are even Web sites that maintain collections of definitions3. The definition I use in this article is that taken from IEEE Std. 1471. This definition follows, with key characteristics in boldface:
Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
Although this definition focuses on software systems, we can apply it to a development environment, too. In our case, the system we are defining is the development environment and the components are method, tools, enablement, infrastructure, and organization, as discussed above. The environment mentioned in the definition represents the context within which the development environment exists and may, for example, acknowledge existing processes, existing tools, existing skills, existing hardware, and the existing organization; quite often, when defining a development environment, we have to work within the constraints imposed upon us. The organization of the development environment, the relationships between elements both inside and outside the development environment, and the principles that guide its design and evolution, are at the heart of the architecture of a development environment.
Other definitions of architecture suggest that an architecture is concerned with both structure and behavior, that it is concerned with significant decisions only, may conform to an architectural style, is influenced by its stakeholders and its environment, and embodies decisions based on rationale. All of these themes, and others, are discussed below.
An architecture defines structure
If you ask anyone to describe "architecture," nine times out of ten they'll make some reference to structure, quite often in relation to a building, or some other work of civil engineering, such as a bridge. Although other characteristics of architecture exist, such as behavior, fitness for purpose, and aesthetics, it is the structural characteristic that is the most familiar and most often mentioned, and this is the same for a development environment. Elements such as method, tools, enablement, infrastructure, and organization represent the structural elements that comprise the development environment.
Many definitions of architecture consider not only the structural elements themselves, but also the composition of structural elements, their relationships (and any connectors needed to support these relationships), their interfaces, and their partitioning. Again, we can apply this thinking to a development environment -- i.e., we must define the various aspects of each of the elements that comprise it. For example, we must define the roles, tasks, and work products that comprise a method, integrations between any tools, the training curriculum and the courses it contains, the hardware and software that comprise the infrastructure, and also the roles and responsibilities within the organization. In addition, it is important to note that there are relationships between these elements and they do not exist in isolation. For example, a person in the organization will fulfill one or more roles defined in the development method using the appropriate tools running on the appropriate infrastructure, and that person will be given appropriate training as a result.
An architecture defines behavior
As well as defining structural elements, an architecture defines the interactions between these structural elements. It is these interactions that provide the desired behavior. As a result of that behavior, we expect certain results.
Let's apply this thinking to a development environment. When the method executes, it guides practitioners in their work, ensuring that the project proceeds in a predictable manner and delivers the desired results. When the tools execute, we expect the production of work products. When enablement executes, we expect practitioners to be trained and mentored, resulting in an uplift of skills. When an infrastructure executes, we expect certain qualities (such as performance of the tools) to be exhibited from the development environment. When the organizational elements execute, we expect the practitioners to receive the support they require from the development environment.
An architecture focuses on significant elements
While an architecture defines structure and behavior, it is not concerned with defining all of the structure and all of the behavior. It is only concerned with significant elements: those that have a long and lasting effect, such as the major structural elements, those elements associated with essential behavior, and those elements that address significant qualities such as reliability and scalability. In general, the architecture is not concerned with the fine-grained details of these elements.
So what are considered to be the significant elements of a development environment? We can consider each aspect of a development environment in turn. The development environment architect is concerned with identifying the roles, work products, and tasks within the environment, but may not be concerned with their details. They are concerned with identifying the tools within the environment, and the required integrations, but are not concerned with the specifics of any configuration required. They are concerned with the training curriculum, but not the details of each course. They are concerned with the hardware and software required to support the development environment, but not necessarily the detailed specification of each item. Finally, they are concerned with the organizational structures and roles that need to be in place, but not necessarily the detailed responsibility of each of the roles.
An architecture balances stakeholder needs
An architecture is created ultimately to address a set of stakeholder needs. However, it is often not possible to meet all of the expressed needs. For example, a stakeholder may ask for some functionality within a specified timeframe, but these two needs (functionality and timeframe) may be mutually exclusive. Either the scope can be reduced in order to meet the schedule, or all of the functionality can be provided within an extended timeframe. Similarly, different stakeholders may express conflicting needs and both needs cannot be achieved in the solution. Making tradeoffs is therefore an essential aspect of the architecting process, and negotiation an essential characteristic of the architect.
This philosophy certainly applies to the architecture of a development environment too, where the development environment architect has to balance the needs of (for example):
- The practitioner who is concerned with intuitive and correct behavior, performance, reliability, usability, availability, and security associated with the development environment
- The system administrator who is concerned with intuitive behavior, administration, and tools to aid monitoring of the development environment
- The customer who is paying for the development environment and is concerned with cost, return on investment, stability, and schedule
- The implementers of the development environment who are concerned with clear requirements and a simple and consistent design approach
- The maintainer who is concerned with a comprehensible, consistent, and documented design approach, and the ease with which modifications can be made to the development environment
- The sponsor who is concerned with aligning the anticipated results from improving development capability with any relevant business or IT strategy
Another stakeholder group, and one that is often forgotten, are the strategic suppliers that may be providing tools, training, infrastructure, and second- or third-line support. Their input can help the architect make appropriate decisions regarding their offerings and the architect may, conversely, influence their offerings. This is not only a technical relationship. For example, an aspect of a business relationship is the vendor's pricing model, which may influence the selection of a particular product.
An architecture embodies decisions based on rationale
Just as important as the architecture itself is the rationale for why it exists in the way it does. You should ensure that decisions are documented along with the rationale for making those decisions, because this information is relevant to many stakeholders, especially those who must maintain the system. This information is often valuable to the architect themselves when they need to revisit the rationale behind decisions that were made, rather than requiring them to retrace their steps. This information is also used when the architecture is reviewed, and the architect needs to justify the decisions that have been made.
The development environment architect must, for example, be able to provide the rationale for making certain tool selections, requesting new hardware to support the development environment, or requiring new practitioner skills that do not currently exist in the organization. The ROI-related implications of the architectural decisions are also an essential part of that rationale. Not only should the development environment architect document their decisions and rationale that led to those decisions but, on a more general note, practice what they preach by following a method. They should automate with tools wherever that makes sense, and they should receive appropriate enablement through training and mentoring, be supported with appropriate infrastructure, and so on.
An architecture may conform to an architectural style
Most architectures are derived from the architecture of systems that share a similar set of concerns. This similarity can be described as an architectural style, which can be thought of as a particular kind of pattern, albeit an often complex and composite pattern (a number of patterns applied together).
[A pattern is] a common solution to a common problem in a given context.5
Like a pattern, an architectural style represents a codification of experience, and it is good practice for architects to look for opportunities to reuse such experience.
[An architectural style] defines a family of systems in terms of a pattern of structural organization. More specifically, an architectural style defines a vocabulary of components and connector types, and a set of constraints on how they can be combined. 6
One of the lessons I've learned from architecting development environments is that there are, indeed, common patterns that emerge from one situation to the next that can be reused. The patterns themselves vary depending on several factors, including the business domain of the organization in question, the size of the organization, and the technologies supported by the development environment (such as particular programming languages).
An architecture is influenced by, and influences, its environment
A system resides in an environment, and this environment influences the architecture. This is sometimes referred to as "architecture in context." From the perspective of a development environment, the architecture may, for example, be influenced by existing methods and any regulatory or organizational standards, any mandated tooling, existing courses that should form part of the training curriculum, existing infrastructure in terms of hardware and connectivity, and existing organizational structures and skills.
Conversely, as eloquently described in by Len Bass et al. in Software Architecture in Practice,7 the architecture may also influence its environment. For example, it may contribute reusable assets to the owning organization. More specifically, a development environment may contribute new methods, tools, enablement materials, infrastructure, and skills to the organization.
An architecture is present in every system
It is also worth noting that every system has an architecture, even if this architecture is not explicitly documented, or if the system is extremely simple and, say, consists of a single element. There is usually considerable value in documenting the architecture -- otherwise it is difficult (if not impossible) to prove that it meets the stated requirements. Architectures that are not documented, which appears to be the majority in existence today, tend to be accidental rather than intentional.
This is equally true of development environments. Very few organizations have historically documented the key elements of their development environment, and have tended to focus on documenting certain aspects only, such as their method, or training curriculum, if they document anything at all. As introduced in Figure 1, the various elements within a development environment are not independent, and there is usually great benefit in documenting the development environment architecture. Such an undertaking could, for example, help identify potential optimizations in terms of redundant infrastructure, or help with understanding the impact of changing the practices used for a particular discipline, such as testing, in terms of method, tools, enablement, infrastructure, organization, and adoption.
What are the characteristics of a development environment architect?
Having defined what is meant by architecture, we can now turn our attention to the role that is responsible for its creation -- the architect (and in this case I mean the development environment architect). The role of the architect is arguably the most challenging on any development project. They are the technical lead on the project and, from a technical perspective, ultimately carry the responsibility for the technical success or failure of the project. The IEEE 1471 standard notes that the architect is "the person, team, or organization responsible for systems architecture."
As the technical lead on the project, the architect must possess skills that are broad rather than deep, although architects should have deep skills in particular areas. In this section I will discuss the characteristics that apply to all types of architect, including a development environment architect.
The architect role may be fulfilled by a team
Given the requirement for a very broad set of skills in an architect, it is often the case that an architect role is fulfilled by more than one person. This allows the skills to be spread across a number of individuals, each bringing their own experiences to bear. Here, as elsewhere in this article, the term "architect" therefore refers to the role, which may be fulfilled by either an individual or a team.
[A team is] a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable. 8
From the specific perspective of a development environment architect, it is often the case that they will draw upon specialists with particular skills (such as a configuration management subject matter expert) to augment the architecture team.
If the architect role is to be fulfilled by a team then it is important to have one individual who is considered to be the lead architect, who is responsible for owning the vision and can act as a single point of coordination across the architecture team. Without this point of coordination, there is a danger that members of the architecture team will not produce a cohesive architecture, or that decisions are not made.
The architect is a technical leader
First and foremost, an architect is a technical leader, which means that, as well as having technical skills, the architect exhibits leadership qualities. Leadership can be characterized by position in the organization, and also in terms of the qualities that the architect exhibits.
In terms of position in the organization, the architect is the technical lead on the project, and should have the authority to make technical decisions. The project manager, on the other hand, is more concerned with managing the project plan in terms of resources, schedule, and cost. Using the film industry as an analogy, the project manager is the producer (making sure things get done), whereas the architect is the director (making sure things get done correctly). As a result of their position, the architect, in particular, should be an advocate of the investment made in creating an architecture and the value it brings to the organization.
In terms of the qualities that the architect exhibits, leadership can also be characterized in terms of interactions with other team members. Specifically, the architect should lead by example, and show confidence in setting direction. Successful architects are people-oriented and take time to act as mentors and coaches to the members of their team. This benefits the team members in question, the project, and ultimately the organization itself since one of their most valuable assets (their people) becomes better skilled. Also, the architect needs to be very focused on the delivery of tangible results, and must act as the driving force for the project from a technical perspective. They must be able to make decisions (often under pressure), and make sure that those decisions are communicated, understood and, ultimately, stick.
The architect has knowledge of the business domain
As well as having a grasp of technology, it is also highly desirable (some would say necessary) for an architect to have an understanding of the business domain.
[A domain is] an area of knowledge or activity characterized by a set of concepts and terminology understood by practitioners in that area. [UML User Guide]
Such knowledge will allow the architect to better understand and contribute to the requirements on the system, and be in a position to ensure that "likely" requirements are captured. Also, it is often the case that a particular business domain is associated with a particular set of architectural patterns that can be applied. Knowing this mapping can also greatly assist the architect.
More specifically, a development environment architect should not only understand the technical aspects of a development environment; it is also highly beneficial for the development environment architect to have some knowledge of the business domain to which this environment will be applied. For example, knowledge of financial services may inform the development environment architect that certain regulatory standards must be supported within the environment, which then influences the processes followed, the configuration of any tools used, and so on.
The architect can "go deep"
Although an architect is not expected to be an expert in everything, they must be able to "go deep" when necessary. This might mean being able to undertake detailed design of a key aspect of the system, even to the point of being able to represent a critical algorithm in a programming language.
The same principles apply to a development environment architect where the architect may, for example, need to understand the detailed implementation of the security within the development environment they are producing in order to ensure access to sensitive information is restricted.
The architect is a good communicator
Of all of the "soft skills" associated with the architect, communication is the most important. There are a number of dimensions to effective communication, and the architect needs to be proficient in all of them. Specifically, the architect should have effective verbal, written, and presentation skills. Also, the communication is two-way. The architect should be a good listener and observer, as well as a good talker.
Being able to communicate effectively is a skill that is fundamental to the success of a project for many reasons. Clearly, communication with stakeholders is particularly important in order to understand their needs, and also to communicate the architecture in a way that gains (and maintains) agreement with all stakeholders. Communication with the project team is particularly important, since the architect is not simply responsible for conveying information to the team, but also for motivating them. Specifically, the architect is responsible for communicating (and reinforcing the communication) of the vision for the system so that the vision becomes shared, and not something that is only understood and believed in by the architect.
The architect makes decisions
An architect that is unable to make decisions in an environment where much is unknown, where there is insufficient time to explore all alternatives, and where there is pressure to deliver, is unlikely to survive. Such an environment is to be expected, and successful architects acknowledge the situation, rather than trying to change it. Thus, the architect needs to be thick-skinned since they may need to correct their decisions and backtrack.
The life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark.9
An inability to make decisions will slowly undermine the project. The project team will lose confidence in the architect, and the project manager will be concerned because those waiting on the architecture cannot make the required progress. The very real danger is that if the architect does not make and document decisions about the architecture, then team members will start to make their own, possibly incorrect, decisions.
The architect is aware of organizational politics
Successful architects are not only concerned with technology. They are also politically aware, and are conscious of where the power in an organization resides. This knowledge is used to ensure that the right people are communicated with, and that support for their project is aired in the right circles. To ignore organizational politics is, quite simply, naïve. The reality is that there are many forces at work that lie outside the project delivering the system and these need to be accounted for.
The architect is a negotiator
Given that the architect interacts with many stakeholders, this role requires negotiation skills. For example, a particular focus for the architect is to minimize risk as early as possible in the project, since this has a direct correspondence to the time it takes to stabilize the architecture. Since risks are associated with requirements, one way to remove risk is to remove or diminish the requirement with which the risk is associated. Hence the need to "push back" on such requirements so that agreement between stakeholders and architect can be reached. This requires that the architect also be able to articulate the consequences of different tradeoffs.
The process of architecting a development environment
Having described the meaning of a development environment architecture, and the characteristics of a development environment architect, I will now consider the themes, or characteristics, that underlie the process of architecting a development environment, which may be creating an environment from scratch or, as is more likely, refining an existing development environment. According to the IEEE 1471 standard:
[Software architecting represents] the activities of defining, documenting, maintaining, improving, and certifying proper implementation of an architecture.
Architecting is both a science and an art
Architecting is a recognized discipline, albeit one that is still emerging. However, with this recognition comes a focus on techniques, processes, and assets that focus on improving the maturity of the process of architecting. One way of advancing this maturity is to draw upon an existing body of knowledge. In general terms, architects look for proven solutions when developing an architecture, rather than reinventing the wheel, thereby avoiding unnecessary creativity. Codified experience in terms of reference architectures, architectural and design patterns, and other reusable elements all have a part to play. However, the experience of an architect always has a bearing on the success of a project.
Although architecting can be seen as a science, there are times when it is necessary to provide some level of creativity. This is particularly true when dealing with novel and unprecedented systems. In such cases, there may be no codified experience to draw upon. Just as a painter looks for inspiration when faced with a blank canvas, the architect may also, on occasion, see their work more like an art than a science. For the most part, however, the artistic side of architecting is minimal. Even in the most novel of systems it is normally possible to copy solutions from elsewhere and then adapt them to the system under consideration.
The development environment architect will therefore consider other successful development environments in their work, but will also be creative as needs dictate.
Architecting spans many disciplines
The architect is involved in many disciplines within the process they follow. The architect is, clearly, most heavily involved in core architecture activities in terms of defining a solution to the defined requirements. However, the architect is involved in many other disciplines, too. For example, the architect may assist with any requirements gathering in order to ensure that those requirements of interest to the architect, in particular, are captured (especially non-functional requirements, such as performance and usability). The architect and project manager also work closely together since the architect has input to the project planning activities.
Architecting is an ongoing activity
Experience shows that architecting is not something performed once, early in a project. Rather, architecting is applied over the life of the project where the architecture is "grown" through a series of incremental and iterative deliveries. At each delivery, the architecture becomes more complete and stable. This raises the obvious question of what the focus of the architect is through the life of the project.
Successful architecting efforts are results-driven. Thus, the focus of the architect changes over time, as the desired results change over time. This is indicated in Figure 2, a figure attributed to Bran Selic, who purportedly drew it on a napkin in conversation with Philippe Kruchten.
Figure 2: Architecting emphasis on discovery, invention, and implementation over time
This figure shows that, early on, the architect is focused very much on discovery. The emphasis is on understanding the scope of the system and identifying the critical features and any associated risks. These elements clearly have an impact on the architecture. The emphasis then changes to one of invention, where the primary concern is to develop a stable architecture that can provide the foundation for full-scale implementation effort. Finally, the emphasis changes to implementation, when the majority of discovery and invention has taken place.
Architecting is driven by many stakeholders
As described above, an architecture fulfills the needs of a number of stakeholders. The process of architecting, which includes the architecting of a development environment, must therefore accommodate all of these stakeholders to ensure that their concerns, specifically those that are likely to have an impact on the architecture, are captured, clarified, reconciled and managed. It is also necessary to involve the relevant stakeholders in any reviews of the solution to these concerns.
The effort involved in accommodating all of the stakeholders in the process of architecting should not be underestimated. The stakeholders influence many aspects of the process, including the manner in which the requirements are gathered, the form in which the architecture is documented, and the way in which the architecture is assessed.
Architecting often involves making tradeoffs
Given the many factors that influence an architecture, it is clear that the process of architecting involves making tradeoffs. Quite often, the tradeoff is between requirements, and the stakeholders may be consulted to assist in making a decision. An example of a tradeoff is between cost and performance, where introducing network compression technologies to a distributed environment will improve performance, but at a cost. This may be a conflict in requirements and, assuming that the architect has been diligent in their work by exploring all options, is a matter that needs to be resolved by the stakeholders whose needs are in conflict. Making tradeoffs is not something that can or should be avoided. It is expected that the architect consider alternatives and making tradeoffs among them is an essential aspect of the process of architecting.
Architecting acknowledges prior experience
Architects rarely work from a blank sheet of paper. As noted earlier, they actively seek prior experience that may be codified in patterns, off-the-shelf solutions, and so on. In other words, the architect seeks out reusable assets. Only the most ignorant architect does not consider what has gone before.
A reusable asset is a solution to a recurring problem. A reusable asset is an asset that has been developed with reuse in mind [RAS]
From the perspective of the development environment architect, a reusable asset might be a method plug-in, a tool configuration, a training course, an infrastructure specification, or a role definition.
The architect may not only consider using available assets, but also contributing reusable assets to the organization's asset repository.
Architecting is both top-down and bottom-up
Many architectures are often considered in a top-down manner, where stakeholder needs are captured and requirements developed, before the architecture is defined, architectural elements designed and then these elements implemented. However, it is rare for an architecture to be totally driven from the top down. An architecture may also be driven from the bottom up as a result of lessons being learned from any skeletal solution that has been created, such as an architectural proof-of-concept. Successful architects acknowledge that both approaches to architecting are necessary, and their architectures are created both "top down" and "bottom up." This could be referred to as the "meet-in-the-middle" approach to architecting.
Benefits of architecting a development environment
In general terms, architecting is a key factor in reducing cost, improving quality, timely delivery against schedule, and delivery against requirements. In this section, my focus is on specific benefits that contribute to meeting these objectives.
Architecting addresses system qualities
The process of architecting is not just concerned with providing the functionality required; it is also considered with ensuring that system qualities are achieved. For example, in order to address performance requirements, it may be necessary to consider the time for each component in the architecture to execute, and also the time spent in inter-component communication.
From the perspective of a development environment architect, it is worth considering that different qualities might apply, depending on the element being considered. For example, a method might be focused on usability and configurability, a toolset might be focused on performance and reliability, enablement might be focused on usability, an infrastructure might be focused on performance, and an organization might be focused on evolvability (the ability to change over time).
Architecting drives consensus
The process of architecting drives consensus between the various stakeholders, since it provides a vehicle for enabling debate about the solution. In order to support such debate, the process of architecting needs to ensure that the architecture is clearly communicated and understood. An architecture that is effectively communicated allows decisions and tradeoffs to be debated, facilitates reviews, and allows agreement to be reached.
Conversely, an architecture that is poorly communicated will not allow such debate to occur. Without such input, the resulting architecture is likely to be of lower quality. On a related note, the architecture can drive consensus between the architect (and their vision) and new or existing members, as part of training. Again, the architecture must be effectively communicated for this benefit to be achieved. Development teams with a good vision of what they are implementing have a better chance of implementing the product as desired.
Architecting supports the planning process
The process of architecting supports a number of disciplines but, specifically, it supports various project management activities such as scheduling, work allocation, cost analysis, risk management and skills development. This is one of the main reasons that the architect and the project manager should have such a close relationship. Much of this support is derived from the fact that the architecture identifies the significant components in the solution and the dependencies between them.
For example, the cost of making a change to the solution requires a level of impact analysis on the solution which would, in turn, follow the dependencies between components to determine which were impacted. In terms of scheduling, the dependencies imply an order in which each of these elements can be implemented. In terms of work allocation, the architecture can again help us to identify areas that require particular skills and therefore particular resources (people) to which work can be allocated.
Architecting drives integrity
One of the primary objectives of the process of architecting is to make sure that the architecture provides a solid framework for the work undertaken by designers and implementers. Clearly, this is more than simply conveying an architectural vision. In order to ensure the integrity of the resulting architecture, the architect must clearly define the architecture itself, which identifies the architecturally significant elements, such as the components of the solution, their interfaces and their interactions.
The architect must also define the appropriate practices, standards and guidelines that will guide the designers and implementers in their work. One of the objectives of architecting is to eliminate unnecessary creativity on the part of the designers and implementers, and this is achieved by imposing the necessary constraints on what they can do, since deviation from the constraints can cause breakage of the architecture. Another aspect of architecting that helps ensure architectural integrity is therefore the adoption of appropriate review and assessment activities. A focus of these activities is to consider the work of the designers and implementers, and determine the adherence to the architectural standards and guidelines that have been put in place.
Architecting helps manage complexity
Systems today, including development environments, are more complex than ever and this complexity needs to be managed. Since an architecture focuses only on those elements that are significant, it provides an abstraction of the system and therefore provides a means of managing complexity. The focus on architecture is also a good way of taking a large problem and breaking it down into a series of smaller problems, by recursively decomposing the system into its constituent parts.
Another aspect of managing complexity is to use techniques that allow abstractions of the architecture to be communicated. The adoption of industry standards that allow such abstractions to be expressed, such as the Unified Modeling Language (UML), is therefore commonplace in the industry today for documenting various types of solutions, including a development environment.
Architecting provides a basis for reuse
The process of architecting can support both the use of, and creation of, reusable assets. Reusable assets are beneficial to an organization since they can reduce the overall cost of a system and also improve its quality, given that a reusable asset has already been proven (since it has already been used).
The creation of an architecture supports the identification of possible reuse opportunities. For example, the identification of the architecturally significant components and their associated interfaces and qualities supports the selection of off-the-shelf components, existing systems, packaged applications, and so on, which may be used to implement these components. From the perspective of a development environment, there may be a method or method content that can be reused, tools or tool configurations that can be reused, courses that can be reused, infrastructure that can be reused, and even organizational roles that can be included as part of the environment (such as an existing Help Desk).
Architecting reduces maintenance costs
The process of architecting can help reduce maintenance costs in a number of ways. First and foremost, the process of architecting should always ensure that the maintainer of the system is a key stakeholder, and their needs are addressed as a primary concern, and not as an afterthought. The result should not only be an architecture that is appropriately documented in order to ease the maintainability of the solution -- the architect will also ensure that appropriate mechanisms for maintaining the system are incorporated, and will consider the adaptability and extensibility of the system when creating the architecture.
This article has elaborated upon the content of a development environment, the architecture of a development environment, the role of the development environment architect, and the process of architecting a development environment. The article concludes with a summary of the benefits that can be derived from a well-architected development environment and how the benefits can add value any organization that is serious about their software development capability.
The author would like to thank Thomas Bichler, Dave Brown, Jos Jennekens, Mike Perrow, and Ton Van Velzen for their feedback on early drafts of this article.
- John P. Kotter, Leading Change, Harvard Business School Press, 1996.
- See Part 4 of this series, which contains links to all four parts, at http://www.ibm.com/developerworks/rational/library/may06/eeles/
- For example, see the Software Engineering Institute (SEI) Architecture Web site -- Architecture Definitions: http://www.sei.cmu.edu/architecture/definitions.html
- IEEE Recommended Practice for Architectural Description of Software-Intensive Systems (IEEE Std 1472000). IEEE Computer Society, 2000.
- The Unified Modeling Language User Guide. Grady Booch, James Rumbaugh and Ivar Jacobson, Addison Wesley, 1999.
- Software Architecture: Perspectives on an Emerging Discipline. Mary Shaw and David Garlan, Prentice Hall, 1996.
- Len Bass, Paul Clements, and Rick Kazman, Software Architecture in Practice, 2nd ed. Addison Wesley, 2003.
- The Wisdom of Teams. Jon R. Katzenbach and Douglas K. Smith. Harvard Business School Press, 1993.
- "The Architects -- The Software Architecture Team," Philippe Kruchten, Proceedings of the First Working IFIP Conference on Software Architecture (WICSA1). Patrick Donohoe (editor), Kluwer Academic Publishing, 1999.
- Participate in the discussion forum.
- A new forum has been created specifically for Rational Edge articles, so now you can share your thoughts about this or other articles in the current issue or our archives. Read what your colleagues the world over have to say, generate your own discussion, or join discussions in progress. Begin by clicking HERE.
- Global Rational User Group Community