4

Agile Architecture and how it increases the Value of SOA

By Peter Jarman

Introduction

Agile architecture has over time developed several meanings, mostly derived from the agile software development approach which adopts a “just in time” architectural development with minimal overhead. In this case the interpretation of agile architecture is more focused on putting in place IT architectures and architectural process which facilitates and embraces changes. In a service oriented environment the various business units and partners can be providers and consumers of services (Both application style services and business operational styles services). In this type of environment even IT architecture should be perceived as an operational service and like all services, it should provide business value, be appropriately costed and “fit for purpose”. This is a key attribute for delivering architectural value within a service oriented environment.

What is IT Architecture?

In order to better describe agile architecture, a good starting point is to have a common understanding on what an IT architect does. Although not explicitly recognized in many organizations, IT architecture is a service which is intended to identify optimal IT solutions, which provide business value while taking into account the multiple forces or constraints applying within the organization. These constraints include aspects such as:

• Organizational structure and culture
• Current/future business needs
• IT strategy
• Enterprise architectural direction
• Cost/value
• Delivery dates
• Best practices
• Project/program guidelines
• Change impacts

Over time businesses tend to evolve to be more complex in behavior and services. This drives an increased divergence and variation across business processes, with the resultant increase in complexity of the IT landscape. One of the key roles of an IT architect is to manage this complexity and look for opportunities to drive it towards simplification where possible.

Figure 1. IT Architecture - Managing IT Landscape Chaos

If this natural tendency to IT chaos can be managed effectively, while at the same time maintaining the agility needed to be responsive to changing business requirements, the end result will be a more effective and responsive IT landscape. This in turn will provide the foundation for a smarter and more agile organization, better able to respond to new business opportunities and to competitive pressures.

In a typical organization the type of services which are provided by IT architecture includes:

• Enterprise integration architecture management
• Development and integration standards and guidelines
• Architecture and design patterns development and maintenance
• Solution governance
• Reuse governance and management
• Common Information Model (CIM) management
• Technology/Product assessment
• Solution architecture/design development
• Service delivery platform architecture
• Planning and estimation support
• Impact analysis
• Quality conformance/design reviews
• Performance engineering
• Architectural principles maintenance

In order to be agile and deliver business value, these architectural services need to be effective and lightweight while at the same time ensuring they are perceived as providing organizational value.

Agile Architecture

Agile architecture is not just about ensuring a flexible IT architecture can be developed; but also about ensuring the architectural process and governance is lightweight and receptive to change. This provides better support for managed architectural level change as new technologies and techniques become available.

One of the more important mechanisms used to support the development of an agile architecture is the extensive use of patterns. Within architecture, patterns can cover a broad range of levels from design patterns, through to architectural patterns and organizational patterns. The key value of using patterns is to allow behavior to be abstracted, analyzed and for designs to be developed to support the pattern.

Figure 2.

These pattern based designs can then be used as templates and design accelerators when relevant functionality to be delivered is confirmed. Patterns cannot be used to architect all solutions, but in key areas such as integration, security, UI behavior, which are more prevalent in service oriented approaches, they are extremely valuable.

In some cases the patterns can be defined to such a degree that they constitute a detailed design. Provided the usage criteria for a detailed reference pattern are well identified, then once an architect/solution designer has matched the functionality to a pattern it can go straight to a developer, or even be semi-automated through the use of tools.

These patterns together with usage examples or scenarios and explicit usage criteria constitute key components of an IT reference architecture or architecture body of knowledge. Such artifacts are extremely valuable for architecture re-use, flexibility and alignment and it is essential they be maintained and extended over time. This brings us to the next key aspect of agile architecture, which is the architecture process. Within an agile architecture process there needs to be explicit inclusion of an architectural feedback process, to ensure valuable knowledge and experience gained can be effectively fed back from delivery projects and programs of work.

Figure 3. IT Architecture - Managing IT Landscape Chaos

These learnings provide reality checks and change management triggers on the various reference architectures, patterns and service models with consequential governance impacts. Project architecture and design activities also provide valuable service identification and validation channels. Figure 2 shows aspects of this feedback process and how it enhances and ensures currency of organizational architecture assets. This explicit feedback aspect (especially back into the enterprise architecture) is often missing in the organizational architecture process, especially those with a project centric IT delivery approach. When it does happen it is usually an unfunded activity dependant on the commitment of individual architects and the relationship with the enterprise architects.

To put in place an agile architectural process, in addition to the standard architecture services identified above, there should be processes and frameworks to cover:

• Implementing ongoing architecture business process evaluation and re-engineering
• A technology change management framework including
  • Best practices and patterns change management process
  • Reference Architecture change management process
  • Platform upgrade impact assessment process
• Service usage and cost of usage data collection
• Pattern identification and verification processes
• Architectural change management process performance data collection and performance analysis
• Governance process performance data collection and performance analysis

In addition to how effective an IT architecture is at responding to changing business requirements, a key measure of architecture agility is not the completeness of architectural artifacts, but instead, the cost (in time and money) of enforcing and changing these artifacts.

SOA

Service Oriented Architecture (SOA) is an architectural approach focused delivering organizational functions as a set of services which can be assembled and composed to deliver the required business function or capability. Service orientation requires loose coupling of services to better support reuse and logically separates the service provider from the service consumer. Although SOA tends to apply to IT delivered technical services, the concept can also apply to other business services.

SOA is intended to provide business value and this value is frequently measured using key performance measures such as:

1. Increase of reuse (of services and existing assets) - This generally leads to reduced operational costs
2. Consolidation of applications and alignment with business processes - This also leads to reduced IT operational costs
3. Increase in IT agility/reactivity - This allows improved time to market and reduced cost of change

Agile architecture provides more focus on the third item, but as in most business situations there are conflicting requirements which need to be balanced. Many SOA related business cases focus on the first two aspects, as these are more easily measured and monetized. However focusing on these aspects only, can often lead to a heavyweight IT analysis process designed to ensure maximum re-use of existing services, systems and infrastructure. This can often result in a situation where IT is unable to respond to changing business needs in a timely fashion. In addition the tendency to treat SOA as an IT initiative also tends to focus more on IT value rather than overall business value can lead to the third aspect being neglected. However the third aspect gains more prominence if IT architecture is treated as a business service.

Many of the SOA technology platforms and tools are intended to provide better abstraction, improved re-use and more rapid service delivery. However this faster delivery time can be substantially squandered if the architectural process is heavyweight. For example in one previous project I was involved in, we managed to substantially improve the service delivery approach to allow new services to be delivered and deployed in a 2-4 week period. However the architectural process associated with service identification/definition and any consequential changes in the message model required up to 3 months to get the relevant changes identified and approved. This was not an agile architectural process, and ensured the entire IT service delivery capability was perceived as poor. This delivery delay increases the risk that the business would simply bypass the IT group for delivery of initiatives, thus reducing architectural influence and ability to manage complexity.

Similar to other organizational activities the SOA service identification and delivery process should be defined and measured. This process needs to be end to end to ensure that impact and value of process improvement can be identified and evaluated. In the above circumstances there were a couple of options to improve the service delivery timelines: improve the process for service identification and message model changes; or bypass this part of the process by reducing the need for it. For example ensure that message model changes are by exception rather than the norm by re-engineering the message model to allow it to be more abstract and thus less impacted by change.

SOA and Agile Architecture Synergies

This is where Agile Architecture can prove valuable as it focuses on responding to changing needs in an effective and efficient manner. To use a line from the Agile Software Development Manifesto, it is about “embracing change”. SOA should not be just about consolidation and increasing re-use, it needs to ensure that IT as a service provider is able to be agile and flexible in order to respond to business change.

SOA can dramatically increase the complexity of the IT environment. The development of composite services and dependencies on multiple service providers across the organization and outside the organization is significantly more complex than managing a large application. In order to take on this level of complexity an organization needs to gain some value in return. Responsiveness to change is a key value which can be provided by this complexity. To ensure the intended technology agility and flexibility is retained, measures need to be put in place to ensure architectural/design integrity and principles are followed to reduce the risk of simply developing a larger and more complex legacy instead. However to be effective, these measure need to be lightweight and effective themselves, also aligned with Agile Architecture principles.

Feedback is also another valuable part of an effective SOA architectural process. Figure 3 shows how this feedback occurs between standards architectural aspects and SOA specific architecture aspects. As identified above for Agile Architecture, the feedback approach for SOA provides a mechanism to manage and embrace change while maintaining an effective SOA reference architecture as part of a framework able to provide development accelerators while maintaining architectural integrity.

Figure 4. Extending Architectural Feedback Mechanisms in SOA

SOA framework processes and artifacts such as:

• SOA best practices and patterns
• Service Catalogue and Common Information Model
• Adaptable software development process
• Services certification process
• SOA Governance
• Service and Platform funding models

already align with Agile Architecture approaches. When you add in additional aspects such as:

• Service usage and cost of usage data collection
• Pattern identification, verification change management processes
• Architectural change management process including performance data collection and performance analysis
• Governance process performance data collection and performance analysis

The end result is not just about service enabling an organization with a focus on reuse and business alignment, but a way of ensuring this approach is not diluted over time to reduce the flexibility and responsiveness to the business. At the same time the effectiveness of the architectural services, which are key to maintaining the SOA flexibility, can be better measured to ensure they remain lightweight and better able to deliver business value.

Final Thoughts

Smarter organizations need to be agile organizations, better able to respond to new business opportunities and at the same time better able to respond to competitive pressures. Agile Architecture and SOA together are intended to deliver a more flexible and responsive IT landscape which is able to more easily respond to changing business needs. Agile architectural approaches are not specific to SOA, but there are natural synergies, resulting from the service delivery paradigm being applied both to IT application services being delivered to the business, and an operational service engagement model focused on delivering effective architectural services. In order to support an effective and agile architecture approach, IT architecture needs to accept they are not immune to organizational process improvement, and preferably be leader in process improvement activities.

References

Kent Beck et. al. Manifesto for Agile Software Development

http://agilemanifesto.org/

Author

Peter Jarman ([email protected]) is a Principal Technology Architect with Infosys Australia. With nearly 30 years of IT experience, he has worked across many industries and technologies. He currently heads up the Australian ES EAIS Practice with a focus on SOA and BPM. Peter also does guest lectures on Enterprise Architecture at RMIT University.