Determining requirements can be difficult. Often the operation of existing applications has taken over the business process requirements to become the equivalent of design or implementation changes. For example, the request "We need to add a column to table XYZ to store the customer code" does not explain why this column is necessary, the business process(es) it supports, or any business rules around the validity, cross-database integrity, and so on. This is not a requirement: It is an implementation decision. By stating the business need at this level, you've lost any ability to analyze the solution and determine the most appropriate method to support the business process. The customer code may exist elsewhere or be derivable from other data. A solution based on this requirement is likely to miss that and create duplication, synchronization issues, and other problems.
In this article, the first in a series on the application architecture discipline, you learn about the requirements modeling aspect of application architecture and explore the skills and competencies, tools and techniques, milestones, and communication process related to the application architecture discipline.
Skills and competencies: Modeling
Your first step in effectively gathering requirements is modeling, which involves creating representations of the architecture to capture requirements, communicating the solution approach, and analyzing the proposed system design. The idea is to use models to represent critical aspects of the system. You can then use these models in formal analysis, simulation, and prototyping to explore predicted system behavior and in documentation or reviews to communicate the system's capabilities and feel.
Domain modeling is when you create a model of the problem domain and divide it into cohesive groups. You can then capture business processes, rules, and data in an abstract model.
The domain model is a tool for understanding the problem domain. It is important that you develop an understanding of the domain outside the information system perspective.
To construct the domain model, you must:
- Identify and characterize the participants (entities) and their actions (activities).
- Identify policies that govern actions (rules).
- Gather information that drives, results from, or records the actions (artifacts/data).
- Divide the factors into subdomains.
- Characterize the resulting domains (core/generic/external) and their interactions.
During this process, a savvy architect will learn a great deal. The resulting domain model and knowledge are the first step in fulfilling your role as the bridge between the problem space and the solution space.
A use case model describes the major interactions between actors (human and other systems) and the system under analysis. The use cases should tell the stories of how the system supports the business processes in the domain and business process models.
The use case model should place the system in context, showing the boundaries of the system and the external actors as well as describing the key interactions between the system and the actors. Use case modeling communicates the system behavior as seen by the stakeholders (for example, users and maintainers).
Component and service modeling
The component model allocates requirements and responsibilities to a hierarchy of subsystems, modules, and components. Each element acts as a self-contained unit for purposes of development, deployment, and execution. Elements of the component model are specified by the interfaces they provide and consume. The internal details are not considered at this point.
A service model defines the application as a set of abstract service interfaces at the external boundary (use cases), between the architectural tiers, and with the generic application and infrastructure (security, logging, configuration, and so on). The set of services that support the application requirements can be matched against existing internally and externally provided interface specifications. The resulting analysis will identify the provisioning strategy and fragment the project activity into specific types based on whether a given service already exists (internal or external, with appropriate activities for each), exists but requires modification (define a new interface and plan for its implementation), or must be built new.
You can measure performance in many ways, the most obvious being how quickly an application performs its key operational tasks. However, as an architect, you must think about several other areas in performance modeling:
- How quickly can the application be built and deployed?
- How much will it cost to build, maintain, and run?
- How well does the application meet its requirements?
- How much overhead does the application incur for those who must use it?
- What impact does the application have on other applications and the infrastructure?
The answers to these questions (and myriad others, depending on context) are critical to a successful application and are usually referred to as the architectural qualities of the application. Modeling these qualities can be very difficult -- even more difficult than the standard quality of performance, which typically addresses the processing and data storage requirements.
You can break this down into the quality attributes of an application, such as:
- Execution time
- Resource consumption
- Development complexity
- Maintenance complexity
Skills and competencies: Analysis
Analysis of requirements means being able to distill the broad business need into manageable units for design and development. You must be able to identify areas of the domain model to which technology can be applied, and then design that application's high-level structure, identifying key components and performance criteria.
Seeing the forest and the trees
Seeing both the large-scale and small-scale aspects and implications of application requirements is an important skill in requirements modeling. Seemingly small details in requirements can have deep and broad implications for the application implementation. You must be familiar with both the problem and solution domains to know which of these are critical requirements and which might simply need a change in wording. You must also be able to evaluate lower-level design decisions in the broader stakeholder context, insisting on a particular choice based on values not clear to the implementors -- for example, maintainability, stability, and reusability as seen in the context of the entire IT capability and strategy. Documenting and defending these decisions depends on the communication skills discussed below.
A significant advantage of models is that you can use them to simulate system behavior. This can take the form of prototypes, mathematical equations, or interaction diagrams. The ability to choose the right model type that will be useful in simulating or predicting some important aspect of the system is critical for the successful application architect.
The use of logic and logical inferences is sorely lacking in most architectural practice. To some degree, this reflects the lack of sophistication in the discipline and the lack of facility that most architects have with analytical techniques. A recent book, Software Blueprints (see Resources), describes a way to analyze requirements and construct an argumentation network that includes the problems, issues, and possible solutions to them. From such an analysis, you can construct predicates from which you can derive implications of proposed solutions and verify that the requirements are met.
Skills and competencies: Learning
Learning refers to the ability to absorb and comprehend new information, then apply that knowledge to analysis of the requirements and the formation of an architecture that solves the problem at hand. You should be capable of acquiring and applying knowledge at varying levels of abstraction simultaneously as well as creating new concepts through synthesis and invention.
Another critical skill for application architects is the ability to create abstractions around the particular requirements that remove specifics and map to a more generic class of problems. This skill is a critical substrate on which other learning skills are built. Be able to abstract detail and recognize patterns (based on intuition tempered with experience and informed by best practices). The successful architect can apply this skill at all levels within the architecture while maintaining the context of higher-level decisions and pattern policies.
Combine two or more concepts, abstractions, or other knowledge to create a new concept that can be used to support the requirements in an innovative way.
So, now that you can create and manipulate abstractions and patterns across all levels of the design space, you can combine and factor them to conform to an existing capability or to invent new ways to approach the problem. For example, knowing that an enterprise development and deployment pattern and framework for applications exists that matches the requirements at hand, you can create and apply the appropriate mappings. Identifying and specifying an extension point in this pattern that leverages a new external gateway product to either improve the pattern or meet additional requirements not supported by the pattern is a deeper skill in the master architect's tool set.
Skills and competencies: Communication
You must have the ability to communicate with stakeholders of highly mixed backgrounds to extract and refine your requirements and to describe the architecture to those stakeholders. You must be prepared to interact in groups of variable size, present to an audience, and have facility with written communication of all types. You must also understand the appropriate techniques for using differing communication channels to a wide range of correspondents.
A good architect must be able to communicate within diverse groups of individuals who have differing backgrounds, skills, and agendas. Mostly, this involves meetings with the various stakeholders, either together or in separate concentrations.
At some point, every architect must present the proposed architecture to a wide audience. The ability to speak effectively and efficiently to a large group is one part of this; the other is preparation of material. You should be able to create clear and effective presentations that avoid large numbers of slides filled with bullet points. Lean toward graphical representations and talk around the diagrams. This requires a great deal of comfort and facility with the topic in question. Reading bullets to your audience will bore and annoy them.
You should be able to use surveys to uncover requirements that are not otherwise clearly generated. Survey questions should be clear, unambiguous, and evocative.
In many cases, you will have to clarify specific requirements with key stakeholders by interviewing them. You should be comfortable interviewing stakeholders at all levels of the organization and across diverse technical and business disciplines. Be prepared with knowledge and questions that help expose the problem domain.
In general, written communication requires more care than verbal communication. It is impossible (emoticons aside) to convey the subtle cues that facial expression and body language impart to face-to-face communication. This is especially difficult in e-mail messages, which can be easily misinterpreted.
Anticipate reactions to your assertions, giving background and rationale for opinions and design decisions. Make everyone feel as if he or she is important enough to you that you are willing to explain yourself.
You should be comfortable and competent with e-mail and the preparation of reports. You should also be capable of turning sometimes vague impressions from interviews, meetings, and surveys into unambiguous statements of the requirements.
Skills and competencies: Prototyping
Whenever one or more requirements imply some activity that is not clearly understood or where the requirements themselves are in question, you can use prototyping to investigate further and feed back into the planning for future activity. This step usually focuses on the user interface (UI) or key uses cases of the application but can also be used for technical issues and product selection.
A prototype can be many things, from a Class-Responsibility-Collaboration (CRC) dialogue to a UI mock-up or working code. Emerging frameworks exist for expressing an object model directly as a working application.
You must be able to lead, document, and facilitate role-playing workshops in which stakeholders play the parts of the various participants in the envisioned application. CRC cards provide a method for exposing and exploring requirements with stakeholders and subject matter experts (SMEs). Each small card documents the name, responsibilities, and collaborators of some entity. You can work through scenarios by having individuals play the parts of the classes. This exercise is particularly useful in domain and use case modeling.
You should be able to quickly generate UI mock-ups that display and communicate system behavior, look and feel, and critical new or risky aspects of the interface. Possible tools include interface builders packaged with integrated development environments (IDEs), diagramming tools, all the way up to auto-generated interfaces based on models.
As an application architect, you need to be familiar and competent with existing frameworks for prototyping, including scripting languages and environments, prototype generators, dynamic languages, and interface builders. You should also be capable of creating new, custom prototype environments that are specific to the application domain or the organization.
Skills and competencies: Enterprise architecture
When working within an enterprise of any appreciable size, you must be aware of the application's context within that enterprise. This is true of the business context as well as the implementation and execution environments.
You should be intimately familiar with the enterprise architecture principles of the organization and with the various formal methodologies for managing and executing development projects. You should also be aware of existing enterprise components, such as security mechanisms, business process and business rules engines, workflow engines, and packaged applications.
Familiarity with the underlying enterprise environment is essential. You should have deep knowledge of the available development tools, middleware platforms, and the standard platforms for application deployment, including their associated characteristics and costs. Knowledge of the skill sets of the development teams can also be very useful in determining the architecture and deciding where development risks exist.
Tools and techniques: Modeling
Tools for modeling currently center on Unified Modeling Language (UML). These tools generally allow for the creation of static and dynamic models of the software, including classes, activity, state, components, and the overall model structure (packages). UML models are defined by a meta-model that specifies the types of objects (classes, packages, and so on) that can be included in the end product model (called a user model). Remember that a meta-model is just a model.
IBM® Rational® Software Architect is an extremely complete and full-featured tool for the architect. Based on the Eclipse framework, the IDE includes support for modeling, Java™ development, Web development, and Java 2 Platform, Enterprise Edition (J2EE™) development. Models can be built by hand, from patterns, or by reverse-engineering code, among other approaches. There is support for creating project templates that contain prebuilt project elements and can be instantiated for a specific project. The templates can include any valid project element, and it is common to include annotated diagrams that help direct the architect, designer, or developer in the expected activities.
Poseidon for UML is a comprehensive UML modeling and code-generation tool from Gentleware. A community edition is available for download at no cost, or you can buy licensed standard, professional, and embedded editions. This tool provides complete support for UML 2 model and diagram types. The professional edition includes support for round-trip engineering and the ability to embed the modeling tool into Eclipse.
ArgoUML is an open source UML model editor that provides support for UML V1.4. One of the most interesting features of Argo is the critic functionality that evaluates the completeness and robustness of the model. This tool also provides all nine diagram types, diagram export, XML Metadata Interchange (XMI) integration, and Object Constraint Language (OCL) support.
The ArgoUML tool has started to address the modeler's cognitive process, with design critics, checklists, and a user model that tailors the critics to the decisions, goals, work breakdown, and skills of the users. ArgoUML also provides a large number of model explorer perspectives based on customizable rules, which allows you to view the model in context-specific ways.
The Eclipse Modeling Framework (EMF) is a Java framework based in Eclipse that provides the basis for building tools and other modeling applications, transformations, and round-trip facilities. The framework is an Eclipse plug-in that provides the required functionality to import and export models from other formats, including Java code, Extensible Markup Language (XML) schema, or Rational Rose®.
Tools and techniques: Specification
An architect should be comfortable with creating more or less formal specifications of the requirements and the proposed architecture that meets them. You should be able to operate across a wide variety of specification techniques and models, applying the appropriate method for the purpose, level of formality, and risk associated with each requirement and the overall application profile.
You should be able to use UML as a specification environment in which to define the static and dynamic structure of the application. You should have complete knowledge of the various UML model elements and diagram syntax and be able to use these effectively for communication and formal specification of the application. Use the OCL to more formally specify the business rules in the domain model and the behavior contracts for objects and components.
XML and its derivatives -- especially the XML Schema Definition (XSD) language -- are commonly used to specify the data exchanged between applications and between components within an application. Use the XML/XSD specifications at the boundaries that exist within or between systems, platforms, languages, tiers/layers, and organizations.
A multitude of formal specification languages and methodologies is available to the astute architect who wants or needs to perform formal proofs that a given architecture or design will meet the requirements. Completeness and correctness are the key advantages to these methods. The down side is the sometimes nearly impenetrable complexity of these specifications and the amount of work required to create and maintain them.
Tools and techniques: Prototyping
The number and variety of tools for prototyping is far beyond what I can cover in this space. In general, prototyping requires a flexible, dynamic tool set that supports the creation of representative functionality in a short amount of time at a very small cost. Most prototyping tools use an interpreted language to specify behavior, allowing for faster development with (sometimes) less rigor and robustness. The key here is to use whatever tool is appropriate to showing how some aspect of the system under analysis will work. I give a few examples below.
The Naked Objects framework is representative of a class of prototyping tools that rely on naming conventions in code along with reflection to automatically generate a UI from the code. The latest versions of this framework are moving away from the convention/reflection method to an external configuration that maps user-visible attributes and operations to the code elements. The resulting interface allows for a fairly sophisticated application in which the domain model can be evaluated. In some cases, this is enough to actually deliver the application.
What results from this framework is a graphical user interface (GUI) in which domain objects can be created and manipulated. Users can create these objects, modify their attributes, create associations between objects using drag-and-drop functionality, and invoke operations. Of course, the business logic must be coded in the operations, but no UI code is required to construct a fully functional prototype. This is a very powerful method for showing and exploring the characteristics of the domain model and evaluating the business logic, with stakeholder participation.
Many scripting languages and environments are available to the architect, each of which provides a flexible, usually interpreted, platform for quickly creating and executing code. Most of these are not suitable for sophisticated UI evaluation but can serve you well for simulation and analysis of performance.
Perhaps the most accessible and inexpensive environment for prototyping is the ubiquitous Web server/servlet dynamic Web. Emerging tools such as Asynchronous JavaScript + XML (Ajax) provide a fairly rich UI toolkit. In any case, prototype applications can be quickly deployed and modified and are accessible to anyone who can reach the server.
Tools and techniques: Containers
Perhaps the most revolutionary tool in software architecture history is the container. A container provides most of the wiring and machinery to deploy application functionality rather than having to code in all these aspects. Deployed components are mapped to the container environment using external (usually XML) configuration files. Some example containers include J2EE Web/Enterprise JavaBeans (EJB) containers, which provide heavyweight platforms for deploying components; lightweight dependency injection containers like Spring that allow for wiring together the objects that make up an application module or component; and publishing or consuming distributed interfaces, automated object persistence, and the like.
Tools and techniques: Tiers and layers
Dividing the application into tiers (or layers) is an essential technique for separating concerns within the architecture. Each tier reflects a common set of capabilities and nonfunctional requirements.
Logical tiers divide the conceptual architecture into components that play specific roles within the application, such as presentation, application logic, business processes, and data access. Physical tiers allocate the components in the logical tiers to the physical platform to which they are deployed. Logical tiers may span physical tiers, and one or more or all the tiers may be allocated to one physical tier.
This section identifies key skill and competency milestones for the application architect as they relate to tools and techniques for requirements modeling. Remember that this is not a static sequence but requires feedback and iteration between the various models and views all the way back to the stakeholder requirements. A design problem at any level should trigger further analysis at higher and lower levels of the architecture.
A domain model demonstrates the architect's knowledge of the problem domain, including the participants, processes, and policies that govern their activities. In an enterprise environment, there is usually an existing model of the domain. In this case, you should identify the parts of the existing model that are related to the application requirements and specify any changes to the model that are implied by the requirements. When this is complete, you can review the new model with the stakeholders, verifying requirements and scoping the subsequent development work. Finally, the proposed system is placed in context within the domain model by documenting which role interactions the system will support.
As application architects, we use the use case model to identify the external boundaries of the application and the interactions that take place at those boundaries. In the majority of cases, the primary interaction is between a user and the system. However, interactions with other systems (internal or external) should also be captured. The result is a kind of stimulus-response view of the system as a whole, without considering the internal implementation detail, focusing solely on events and information exchanged at the boundary.
The completed use case model should allow all the stakeholders to see how the system supports their roles. As such, the model can be extended to include use cases for all aspects of the system operation. The architecture of a system should consider all aspects of what it is like to own and use the system.
The use case model should capture all these stakeholder interactions as they are discovered. The first-cut model should probably focus on the core functional requirements, with additional use cases added later to support the nonfunctional aspects. Alternatively, you can create different model views for specific types of stakeholders.
I use architecture here as an umbrella term for a set of models and mappings that represent the high-level design of the system. When the domain and use case models are understood and specified, you can derive the following points:
- Service model. Identifies and specifies the services that the system offers to other internal and external systems and within the application itself.
- Component model. Identifies the subsystem/module/component structure of the application.
- Service/component mapping. Maps service specifications to component specifications; identifies which services are provided by which components along with any necessary adapters and orchestration.
- Performance model (optional). Identifies key performance metrics for each component and specifies the overall performance goals of the application; should be suitable for performance analysis and simulation of system operation.
- Tier partitioning. Keep the architectural tiers in mind as you construct these models. Components should not cross tier boundaries, and services are useful for encapsulating the components within a tier, especially at the mid- and lower-level tiers.
With all the high-level design in hand, you should now be able to plan the work ahead. The work breakdown should identify and characterize all the subprojects that will build, buy, reuse, or adapt the system components. Take into account, and tailor the architecture to, the different kinds of work to be done. At a broad level, the work should be divided into activities that are solution specific (UI, application flow) and solution independent (business processes, entities). Next, divide each of these by the type of work to be done: build, evaluate and buy, adapt and extend, and so on.
You can see a direct relationship between the problem domains that software addresses and the solution domain within which that software is built and executed. In requirements modeling, your role is to explore, elaborate, discover, and create that relationship. To do this, you must identify and communicate with stakeholders, document and present your findings, build and analyze models, and create a buildable design that satisfies the requirements within time and budget constraints.
This dense but succinct definition explains what an architect must do to effectively capture and refine requirements. In general, the architect must be knowledgeable at all levels and be interested in bridging the gap between problems and their solutions. You must be committed to the role to play it well. Above all, the architect role requires communication with and between diverse audiences. Cultivate empathy, and learn to use the most important communication tool: listening.
Learn
- CBDi Forum (now joined with Everware) is an
extensive resource for information on component-based software engineering and
Service-Oriented Architecture (SOA). Many articles are available free to registered
users. Additional in-depth materials are available to "Silver" or "Gold" (corporate) members.
- SEI Series in Software Engineering
is a series of books on building, documenting, and evaluating software architecture
and product line practice.
-
The Association for Computing Machinery provides a vast
digital library of academic papers, conference proceedings, and practitioner reports
on all aspects of computer science, software engineering, and software development.
There is also a library of online books and courses. (Note that these are available
only to ACM members.)
-
The Object Management Group (OMG) owns and maintains
the UML standard and related standards for the Meta Object Facility (MOF) and other
model specifications.
- OMG Certified UML Professional
is a certificate program demonstrating facility with all UML model and diagram types.
- IBM Certified
Specialist for Rational Object Oriented Analysis and Design is a certificate
program demonstrating facility with all UML model and diagram types.
- IBM Certified Solution
Designer - IBM Rational Software Architect is a certificate program demonstrating
facility with all UML model and diagram types.
- Certified Requirements
Management Specialist is a certificate program demonstrating facility with
requirements management and use case modeling with IBM Rational tools.
- Certified SOA
Professional from IBM and IBM Rational software demonstrates the ability to translate requirements
into an SOA.
- Certified RUP
Specialist from IBM and Rational demonstrates the skills required to apply the
Rational Unified Process (RUP) to a development life cycle.
- WebSphere
Certification from IBM covers various aspects of the IBM WebSphere® product suite.
- Java
Platform J[SEM]E Certification - certification programs for all levels of the Java
platform.
-
The Certified
Software Architect/Evaluator/Facilitator program at SEI demonstrates a foundation
in the creation, documentation, and evaluation of software architecture.
-
The Certified Product
Line Architect program at SEI demonstrates facility with the product line
architecture technique for specifying classes of software systems that share
requirements.
-
Read Software
Blueprints: Lightweight Uses of Logic In Conceptual Modelling, by David
Robertson and Jaume Agusti (Addison-Wesley, 1999).
- Stay current with developerWorks technical events and webcasts.
Get products and technologies
-
Download IBM
product evaluation versions and get your hands on application development tools
and middleware products from DB2®, Lotus®, Rational, Tivoli®, and
WebSphere software.
Discuss
- Participate in the discussion forum.
-
Check out developerWorks blogs
and get involved in the developerWorks
community.
Christopher Caserio is an IT Architect with a leading insurance company. He has been involved in the development and design of software systems for more than 25 years, playing many roles during that time. He started Objex Consulting in 1993 to provide enterprise architecture and software design and development services to clients. You can reach Christopher at cppc@acm.org.
Table of contents
- Skills and competencies: Modeling
- Skills and competencies: Analysis
- Skills and competencies: Learning
- Skills and competencies: Communication
- Skills and competencies: Prototyping
- Skills and competencies: Enterprise architecture
- Tools and techniques: Modeling
- Tools and techniques: Specification
- Tools and techniques: Prototyping
- Tools and techniques: Containers
- Tools and techniques: Tiers and layers
- Milestones
- Summary
- Resources
- About the author
- Comments