Notes by Ian De Silva
Lean and Mean Architecting with Risk- and Cost- Driven Architecture
Eltjo Poort, CGI
Solution architecture includes more than just the software; it may include business processes, information systems, technologies, and the environment. Solution architecture approaches fill the gap between enterprise architecture approaches and technical architecture approaches. Enterprise approaches are weak on transformation and implementation, while technical architecture is weak on cross-technology stakeholder concerns.
In particular, Eltjo is interested in Risk- and Cost- Driven Architecture (RCDA). RCDA is a repository or practices—that is, a repository of light-weight, proven methods for addressing a problem. These practices can be adopted piecemeal by the development organization.
Why RCDA? Because costs and risks really drive the architecture, as they are typically the most important concerns. These need to be minimized by the project. Architecture should also be minimal because architectural decisions limit downstream decisions when more information is available. Thus, a minimal architecture allows greater flexibility.
RCDA practices are based on what the architect does daily (the core practices): identify and prioritize architectural concerns, research possible solutions, and decide on and evaluate the best fitting solution. These practices, performed iteratively, make up the RCDA workflow. The identification and prioritization is essentially a backlog. The result of the workflow is a set of architectural decisions. After making the decision, the architect needs to figure out what the architecture is going to cost, evaluate the risk, then allow the start of implementation.
To support the core practices, specific, extension practices and lifecycles are used, allowing the tailoring of the method to the needs of the organization.
RCDA is a method that is lean, mean, and agile. The practices eliminate waste, making it lean. The risk and cost focus support the business decisions, making it mean. The iterative decision-making process makes it agile.
Product Analysis Jump-Start Method: Consider the Big Picture Before you Sprint into Your Project
Stephen Letourneau, Sandia National Labs
Have you ever been overly focused on, say, a GPS, and not what places are around you? C’mon, you know you have. Most of us have blindly followed the GPS or even just focused on the next turn in the trip. This happens in development as well, when we don’t have an architecture, or we have an “emergent architecture.” What do you do when you get to a quality attribute requirement such as a security requirement? Well, we use a “refactoring iteration” to rearchitect the system. We could have benefited from an architecture that built in the quality attributes at the beginning of the project, or that we could have changed and communicated within the team more effectively.
Stephen suggests using a product analysis jump-start. This approach attempts to create the “bones” and “lets the development team put the meat on the bones.” The analysis jump-start workflow starts with understanding the business processes and developing a vision. Next, Stephen suggests developing a candidate architecture, mapping quality attributes to features. Finally, during close-out, the risks are prioritized, the architecture is communicated to stakeholders, and a project/product plan is created.
What are the benefits of this approach? It establishes agreement on what is being developed (created a project vision), builds a common understanding on why it is being developed, and identifies the major components. Unfortunately, it is difficult to only do “just enough” architectural design, to stay focused on the outcomes, and to get customer participation.
This is not a one-size-fits-all approach. You will need to tailor it to your organization. Further, it must be conducted fast to fit it into an iteration 0 and reduce waste.
In conclusion, this approach helps to ensure that we build the right system at the outset, providing a direction to keep the team “on-course.”
Introducing Design Pattern-Based Abstract Modeling Construct as a Software Architecture Compositional Technique
Sargon Hasso, Wolterskluwer
So you have the components for a system designed at the class level. How do you integrate these components? Can design patterns be used to integrate these components? Sargon presents a method for integrating components using design patterns. He does this by abstracting out the behavioral collaboration model (the collaboration between components) from the design patterns, using a role-modeling construct. This allows the behavior to be abstracted from the design pattern to show the collaboration among the components.
Let’s illustrate this with an example. Say you have three components for a resort’s room management system. Say we have a component for room reservations, a component with the resort’s organization, and a component for the resort’s services. We want to connect these components. Sargon recommends connecting these components with patterns one level up. In the example, we can use an adapter pattern to connect the resort’s organization and the resort services components. In this way, the behavior between the components are modeled and used to connect components.