Using Patterns in Architecture to Reduce Risk
By Peter Jarman , Principal Technology Architect - Infosys (peter_jarman(at)infosys.com)
This paper is intended to provide an insight on the value of using patterns in solution architecture and how the use of patterns will assist a project to better manage and reduce both architectural and delivery risk.
What are Patterns
Within architecture, patterns can be identified and leveraged across a number of levels, from lower level design patterns, through to more abstract high level architecture and organization patterns. Patterns are a mechanism to allow common behaviors to be abstracted, analyzed and defined in terms of a template for repeatable design and implementation of the generic behavior. These pattern based design templates act as design accelerators.
Patterns cannot be used to architect all solutions, but in key areas such as integration, security, and UI behavior, they are extremely valuable. These patterns together with usage examples or scenarios and explicit usage criteria form significant components of an IT reference architecture or architecture body of knowledge.
Examples of Patterns
For an Architect, patterns can be at various levels. Some examples of these different types of patterns are:
- Order provisioning and fulfillment
- Federated enterprise (Where relevant business units are fairly independent with their own business processes. For example a holding company)
- Integrated enterprise (Where business processes are viewed and managed end to end across the entire organization)
- Security - Identity Federation
- Security – Centralized Identity
- Security - Single Sign On
- Integration – B2B gateway
- Integration – Enterprise Service Bus
- UI Content - Development with staging content server
- UI Content – Development on production server
- Security - Web Single Sign On – with federation
- Security - Web Single Sign On – with back channel credential
- Integration – File Transfer
- Integration – request/reply
- Integration – fire and forget
- Web UI –Breadcrumb navigation trail
- Standard design patterns such as those identified in the Design Patterns book by Eric Gamma et. al.
Architecture and Patterns
What is significant about patterns in that although they are not all at the same level, conceptually they are a means to abstract behavior across people, process and technology to allow an understanding of potential solutions, issues, constraints and risks on the basis of history. A pattern becomes relevant to an Architect if it is repeatable and re-usable.
Re-use of patterns and the knowledge associated with the patterns is not project specific but can also apply across projects. This is the body of architectural knowledge aspect. A key role of an architect is to use their experience and knowledge to define and validate solutions at various levels from high level logical to detailed physical. Patterns allow an architect to solve problems not just based on a real “I have seen this before and know how to do it”, but on the more abstract pattern aspect of “I am aware of similar situations and these are the approaches, issues and risks associated with it”.
In some cases a pattern can be defined to such a degree that it constitutes a detailed design template which can be leveraged to develop a “cookie cutter” approach to implementation, which can even be automated to some extent. In order to support a “cookie cutter approach”, the usage criteria for each detailed reference pattern need to be well defined.
The usage criteria are extremely important to ensure anti-pattern (incorrect usage of a pattern) scenarios do not occur.
In addition to handle changes over time in how a pattern will be optimally implemented, the patterns need to be versioned in some fashion and these versions need to be tracked.
Value of Patterns
Patterns provide a number of key benefits:
- Improved repeatability
- Improved productivity
- Reduced documentation cost and maintenance.
- Improved quality
Change Management aspects
- Reduced support/change cost
- Better support for managing upgrade/product enhancements
- Improved long term alignment
- Reduced risk of design re-work
Productivity - Reduced Service Delivery Timelines
If the usage criteria are well defined, then all the architect/solution designer needs to do is matched the functionality to a pattern and then it can go straight to a designer/developer. The developer can then go directly to the detailed design and development based on the pattern design details.
If the usage criteria are not well defined then architect/solution designer needs understand the positives and negatives for each pattern and make an informed choice. However at this point it can also go straight to a developer.
This approach reduces documentation as only the pattern and example scenarios are documented in detail, instead of replicating the design detail for all functionality.
Productivity - Reduced Requirements Verification/Clarification Effort
The value of using patterns is that an architecture can be defined using the patterns in a more abstract fashion. The requirements can then be mapped across the patterns using a gap analysis approach.
The key need is to ensure the patterns defined in the architecture provide full coverage, so it requirements clarification focuses on where the requirements are not covered by the patterns. This ensures there is a focus on clarifying requirements, only to the level to verify they are covered by an existing pattern, allowing requirements clarification activities to be concentrated on those areas where there is an architectural gap or where more detail needs to be developed to match a pattern.
Productivity – Supports a Testable Baseline for Product Upgrades
One very useful advantage of using pattern based designs occurs when a product platform changes. In a patterns based implementation, once pattern is tested, then any required changes can be easily replicated across all the implemented instances of a pattern.
On interesting aspect is over time as product platforms change, the detailed design aspects of a pattern would evolve in an ongoing fashion, in order to optimize the use of the supporting platforms/products. Most organizations would not be upgrading everything at the same time, so the result will be a number of different pattern implementations. This drives another significant concept for pattern based architectures, and that is the need to version manage the patterns.
Change Management - Reduced Impact of Change
Using patterns often allows the deferment of build activities until closer to the required delivery time. It better allows the scheduling of service builds based on project dependencies (Just in time service delivery). This provides a more agile delivery approach which is reduces the impact of change by not building until needed.
In addition the scope and impact of requirements change focuses on whether there is a need to change the supporting pattern.
Governance - Architectural Alignment via Approved Patterns
Using patterns often allows architectural governance via reference architectures and designs. Solutions can be developed using pre-approved patterns, dramatically reducing the governance effort and substantially reducing the chance of rework resulting from architectural misalignment
Risk Mitigation using Patterns
So how does using patterns reduce or better mitigate project risk?
Project risk management and mitigation is supported in the following ways:
More responsive/reduced cost of change
- Agility can be defined as the ability to respond to change with minimal noticeable impact. In a delivery project situation, changes often result in key activities moving onto the critical path. Agility better provides the project with the capability to respond to these changes and quickly move the activities out of the critical path, or at the very least reduce the risk of the critical path activities over-running. Patterns are one means of supporting this agility/responsiveness to change.
Usage of patterns to define and manage scope
- One key challenge in working with unclear requirements or using agile project methodology approaches is how to manage scope. This is where a patterns based approach can be used to better manage scope risk. The general approach is to define scope in terms of patterns and numbers of pattern instantiations, in a similar fashion to ho agile projects limit scope based on numbers of stories to be implemented.
The first implementation of a pattern proves it for subsequent implementation
- In a similar fashion to using prototypes and proof of concepts, the first implementation proves the pattern and reduced the risk of subsequent problems in subsequent implementations.
Product version upgrades can be tested at a pattern level and any
required changes applied across all instantiations of the pattern
- This is more an operational support risk rather than a delivery risk, although there are often circumstances when an upgrade/product change needs to happen mid-project. In this case similar to item 3 above once the change has been proven for one instance of the pattern, there is a much lower risk of problems for other instances of the pattern
Allows focus to be put on the key unknowns/gaps to detail these out
rather than requiring comprehensive effort around lower risk
- Patterns allow the use of a variation of the requirements process (similar to that used for product implementations), where the focus is put on gaps and misalignment rather than on known aspects. When clarifying requirements, once functionality is verified as being supported by existing patterns, then it can be ticked off. This allows the focus to be put on the unknown and thus higher risk functionality. This will often result in varying levels of requirement details across the project, but forces detail to be developed in the high risk areas.
In summary the use of patterns in architecture and design provides the ability to be more repeatable and more responsive for solution delivery. This is based on leveraging previous pattern implementations to prove parts of the solution making them low risk, while at the same time mitigating other risks by providing the opportunity to focus on the unknown areas.