The SPAMMED Architecture Framework

The SPAMMED Architecture Framework Arnon presents here helps you identify the steps and activities you need to design, model, and build successful architectures.


September 07, 2006
URL:http://www.drdobbs.com/security/the-spammed-architecture-framework/192600570

Arnon is a software architect with 16 years of experience building large, complex distributed systems on various platforms ranging from HP-UX and Solaris to AS400 and Windows. Arnon blogs at http://www.rgoarchitects.com/blog/ and also writes the Dr. Dobb's Portal blog on software architecture and design at http://www.ddj.com/dept/architect/. He can be contacted at [email protected].


Congratulations! You have just been made lead architect for your company's next flagship project. The project, whose initial estimates range from 200-300 man years to complete, is both complicated and important—and under the C-level microscope. Where do you start?

Enter the SPAMMED Architecture Framework (SAF). SAF identifies the steps and activities you need to design, model, and build successful architectures. But designing software architectures is not just the modeling. There are all kinds of activities that help ensure that the model is usable and that the architecture is successful; hence, the acronym "SPAMMED," which:

Identify Stakeholders

Identifying a project's stakeholders and their concerns, agendas, and needs is the first task architects should perform when starting on new projects.

Who are stakeholders? They are the people who have some vested interest in the project. Naturally there are many stakeholders with any project—customers, targeted end users, operations (IT), developers, maintainers, management, testers, and so on. Stakeholders also include the architects themselves.

It is important to catalog project stakeholders, as the architect's role is to strike a balance between the (sometimes conflicting) concerns and agendas of stakeholders versus the project's functional/nonfunctional requirements. Stakeholder needs/concerns can impact the architecture. The most obvious example is a time constraint; for instance, "finish the project in two months or don't do it at all." Such constraints are bound to have an affect on the possible complexity of the architecture.

The place to start is to build a mental model of the stakeholders in the project. Keep in mind that the reality is that not all stakeholders necessarily want the project to succeed. You can map the stakeholders by their interest in the project, their power, and the importance of their concerns. As a rule, you should closely manage the stakeholders who have lots of interest in the project and who can influence its success. Keep stakeholders who have low interest but high influence satisfied; keep the stakeholders who are interested but have low influence informed, and monitor the rest (see "Another View at Enterprise Architecture Viewpoints," by J. Schekkerman; www.enterprise-architecture.info/Images/ExtendedEnterprise/E2A-Viewpoints_IFEAD.PDF).

List Principles, Goals, and Constraints

Designing architectures is a tough and complicated job, and the solution space is virtually endless. To help you focus and limit the solution space, you can use three tools:

Stakeholders don't just sit there with their concerns and agendas—they can also introduce constraints related to: business (time constraints); technology (the company standard is to use WebSphere, for instance); or architecture. For example, on one of my recent projects, the customer required that the solution incorporate a parallel processing engine (grid) and that a single engine would be used in all subsystems that required parallel processing.

It's important to remember the constraints when you model solutions. I usually document each constraint, explaining what it is, its rationale, which stakeholder introduced it, and the scope of its effect.

Goals are similar to constraints in that stakeholders originate them. The difference is that while constraints are demands, goals are more on the "nice to have" side and tend to be more amorphous; for instance, you want the architecture to be open and based on standards.

Principles draw on our past experiences. Using principles from other similar projects can increase the chances you will be able to reuse assets from those projects. For example, a principle might be "we think that a federated database can work for this solution because it proved to be the best option in three other similar projects." You can document principles in a more formal manner by describing what they are, the rationale behind them, the benefits they bring, their liabilities and implications, the alternatives, and the scope of their effect. It is usually more worthwhile to manage principles in larger projects. Regardless of project size, and whether you carefully document principles or just spend some time thinking about them, you should be ready to forgo any of them if/when the actual requirements of the system at hand show they do not fit.

Discover Quality Attributes

Architecture is mainly concerned with ensuring that the system's quality attributes are covered. By quality attributes—also known as "nonfunctional" requirements or "ilities"—I mean requirements that have system-wide implications and cover areas such as performance, security, availability, flexibility, usability, testability, and the like.

Discovering or hatching quality attributes is extremely important because they provide the basis for modeling the architecture. I recommend using the scenarios-based approach detailed by Paul Clements et al. in Evaluating Software Architectures: Methods and Case Studies (Addison-Wesley, ISBN 020170482X). With this approach, you construct a "utility tree" that demonstrates the overall goodness of a system. The base quality attributes are refined to specific areas that are then further refined to scenarios in the application where the attributes are evident (the scenarios are used both for modeling and testing/evaluating the architecture). This is best explained by examples such as Figure 1.

[Click image to view at full size]

Figure 1: Scenario examples.

Once you have more than one quality attribute nailed down, it is important to prioritize them because it is unlikely the architecture will be able to address all of them (at least not equally). Prioritization doesn't have to be performed by the architect alone. It can be wise to get other stakeholders involved in the process. Doing so helps everyone understand the trade-offs later in the game.

One quality attribute the architect should introduce is flexibility. Architectural decisions are relatively hard to change. You should try to allow even a small amount of flexibility into the design because requirements are sure to change.

Model

Modeling is the most obvious activity. It can be done on whiteboards, with case tools, or even with a word processor. The level of detail depends on the requirements (sometimes a customer demands a detailed document as part of the contract), the team level (experienced developers require less detail than inexperienced ones), and the development process (Agile processes require less documentation).

Another point to remember is that design should be conveyed from multiple viewpoints (see IEEE 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems, ISBN 0738125180). Each stakeholder has different concerns and different viewpoints that help demonstrate how the architecture addresses these concerns. For example, a deployment or physical view helps communication with operations and/or system engineers by demonstrating what software runs on what hardware, the hardware needed, the network topology, and the like.

Map to Technology

Granted, mapping technologies is not an architectural activity per se. Choosing one technology over another usually will not change the quality attributes of the system. However, the architectural implications become evident when the wrong technology is used. For instance, using Microsoft Access where Oracle RAC 10g should be used will greatly affect performance and availability. Another problem that can occur is misalignment of the technology (to the architecture). The result is hard work for the development team, which can, in turn, result in rejecting the architecture all together. For example, if you decided to build a rich-web client (AJAX, for instance), servlets are probably not the way to go about developing it.

Another aspect of mapping to technology is to make decisions involving buy versus make versus reuse versus customize.

All of these decisions are similar to architectural decisions in that they tend to have ripple effects solution-wide. Also, technology decisions affect the detail design. For example, if the project needs some way to move messages around, it is always possible to start at the socket level and develop some proprietary solution. Or maybe you can buy a JMS solution. However, if you are using SQL Server 2005, why not utilize a service broker? Or maybe web services interoperability would be better.

Evaluate

Architectural decisions are made early, and once made, they're hard to change. This means that it is extremely important for you to ensure that architectural decisions are right. To me, the premise of "test early/test often" is also applicable to architecture. Thus, once you have made some decisions (while modeling and mapping), you want to evaluate your decisions and validate your assumptions. An artifact that can help you in evaluating architectures is the quality attributes scenario. In fact, this is the way it was originally used in evaluation methodologies, such as ATAM.

It is preferable to evaluate the architecture in code; after all, this is how it will eventually be used. There are several possibilities for evaluating architecture in code—simulations, proof-of-concept (just enough code to validate a single decision), prototyping (making several architectural components work together), and building a skeleton (similar to prototyping, except the end result is the basis for further development). When you test the architecture in code, you can also use additional techniques such as Test-Driven Design (TDD) to further refine the design.

If you are still looking at the system in a higher level of abstraction (compared to code), it can be harder to dive to code, so you can draw on formal evaluation methods. The Software Engineering Institute (www.sei .cmu.edu) offers several evaluation techniques (ATAM, ARID, and the like). Microsoft introduced one (LAAAM) as part of MSF 4 for CMMI improvement , CERT has Survivable Network Analysis, and there are others. Evaluation on paper can take between a couple of hours to several days, depending on the method used. Formal evaluation requires the participation of various stakeholders to be successful. Both evaluation approaches (evaluation in code and on paper) complement each other to help you make the right decisions.

Deploy

Once you are satisfied with the current state of the architecture, deploying it is the next activity. Deployment means that development teams utilize it for developing system functionality (this can be early in the process if you are part of an Agile team). If you are a responsible architect, this doesn't mean it is time to disengage—far from it.

There are two motivations for you to continue working with the teams:

Conclusion

Designing a software architecture is not just the modeling itself. There are other activities, identified by SAF, that help ensure that the model is usable and that the architecture is successful. But SAF is not a process. When you perform one activity, you should go back over and over to adjust/rethink some of the other ones. The obvious example is that once you evaluate your model, you need to fix it according to the results of the evaluation. Figure 2 illustrates some of the common transitions.

[Click image to view at full size]

Figure 2: The SPAMMED process.

In short, SAF is not the end result—it is the starting point. Your role as an architect is to fill each of these activities with meaningful substance relevant to the project at hand.

DDJ

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.