- Developing UML Architecture for EAI Products
- Process for Building an Architecture
- Addressing Architecture Issues Specific to EAI Products
- Example Solutions to EAI Issues
- Conclusion
Process for Building an Architecture
The following process has been developed over the course of several EAI projects. The model seen in Figure 1 provides a step-by-step guide to the overall process of developing architecture for EAI products.
){kind=link}
The process model for Developing EAI Architecture shows the steps of the overall process that are followed to build a set of architecture models for EAI products.
The steps of the process are listed next, and detailed instructions for performing each step follow:
- Define your goals and priorities.
- Identify participants and roles.
- Determine architecture requirements (components).
- Gather project/system information (interviews, doc, etc.).
- Develop 1st iteration architecture models.
- Review and improve (adding sufficient detail).
- Present final deliverables (may be ongoing).
1. Define Your Goals and Priorities
Defining your goals and priorities for the architecture development will provide a road map for the project to follow. Your goals may include one or all of the benefits listed in the "Benefits of UML Architecture" section of this article, or other goals specific to your situation. Getting clear about which goals you are pursuing and the order of their importance is very important to building a project that your organization can support.
2. Identify Participants and Roles
Determine which areas of your company are affected by the product in question, and which customers and suppliers might also have a role in architecture definition. Affected areas may include some or all of the following:
- Sales and marketing
- Research and development
- Engineering and design services
- Customer service and support
- Customer focus group or specific client
- Fulfillment and installation groups
- Contract groups and legal advisors
- Standards bodies both internal and external (customer)
- Customer review boards that will evaluate results
After determining who's involved, you need to define what role individuals will play in the project. Contributor, leader, subject matter expert, reviewer, and coordinator are some of the roles required.
3. Determine Architecture Requirements
Set initial goals for the types of models that should be included in your product architecture. This list should be revisited occasionally and updated as the project proceeds. Some typical deliverables for product architecture include the following:
- Actors
- Use cases
- Interfaces
- Dependencies
- State charts
- Use case activity diagram
- User interface overview
- System class relationship diagram
- System blueprint diagram
- Component responsibility model
- Deployment model
- Use case sequence diagram
- Technology inventory
- Risk assessment
4. Gather Project and System Information
Interview your company's subject matter experts and conduct research and interviews with outside experts to gather relevant project and system information. Business processes and information should be documented and evaluated for reengineering requirements. Existing documentation and requirements statements can provide a starting point for modeling efforts. Training and user documentation often provide clear descriptions that can be converted to use case documentation. Depending on the goals of your architecture, client interviews may fill in the blanks on requirements modeling.
5. Develop 1st Iteration Architecture Models
Using the materials gathered in step 4, develop a first draft of the most significant architecture models, including use cases, both graphic and narrative, collaboration diagrams illustrating the most important use cases, and high-level class diagrams for data architecture. Components can be identified in class diagrams, and employed in collaboration diagrams. Depending on reengineering requirements, business models may be elaborated for this step. Component responsibility, deployment models, and technology inventory will be detailed as the required information becomes available.
6. Review and Improve
First iteration models should be reviewed with the parties identified in step 2, including any members of reviewing boards who must sign off on the project results. Reviewers should be apprised of project plans early in the process to reduce the risk of expensive surprises at project conclusion. As participant buy-in is achieved, models are carried to sufficient levels of detail to deliver the identified goals of the architecture.
7. Present Final Deliverables
Architecture development will typically include a milestone or milestones for reporting of results achieved by the project. Architecture components are often delivered in the automated tool in which the models were developed, so that they can be extracted and embedded into various types of development and project documents. This process may be ongoing, as in the case of multiple releases of products that are delivered in response to dynamic requirements definition.