Guide to SOA and the cloud
A comprehensive collection of articles, videos and more, hand-picked by our editors
The cloud is almost the embodiment of IT change. One of the most commonly referenced drivers of cloud evolution is the need to make applications more Agile or responsive to changes in need or opportunity. Given the dominant role of SOA in applications, it's critical that SOA practices be tuned to cloud agility goals. For cloud and application architects, that means:
- Understanding what is meant by Agile,
- Enforcing what SOA can and should already be doing, and
- Addressing architectural limitations on agility that SOA can bring.
For many SOA architects, the topic of SOA Agile design may seem redundant. From the start, one of the specific objectives of SOA was to foster agility. The primary problem with SOA Agile design is redefining the notion of agility, and making the changes track into architectures and workflows for SOA.
The Web has encouraged the notion of Agile development, meaning the creation of applications through a broadly collaborative set of activities that cross team boundaries and that proceed iteratively. SOA's agility goals are based on component reuse and loose coupling among components to promote component reuse in new applications.
Aligning modern Agile design concepts with SOA componentization
Application architecture may be the key to syncing SOA componentization with agility concepts. To an application architect, a business function is essentially an atomic piece of an application, almost a statement in a programming language. Good application architecture should identify the functional pieces of all applications, and thus be a good way to spot reuse opportunities. Certainly, for new projects, classic modern concepts of application agility can be encouraged by doing a functional-level architecture and using that as the basis for componentization.
The problem with this is that most Agile development is being fit into a SOA-componentized world not of its making. Architects try to preserve current component structures to minimize transition costs, which only creates a worse problem down the line. The biggest issue with SOA componentization isn't that it's not helpful; it's that it's not done. Every architect knows reuse is a primary goal, and yet many don't enforce the reuse of components in design.
The only way to fix the problem is to mandate that when Agile design development identifies reuse opportunities that existing components don't support, the components are changed to fit. Most companies will find that this approach will gradually work them out of the failure to enforce logical componentization programs.
Iteration and cross-team collaboration can be achieved only by starting with a functional architecture and working downward in layers, defining components first as shells with interfaces set, then filling in the logic through collaboration. Where needed, these high-level components can be decomposed into lower-level structures. However, it's best to keep the initial function-based component model intact to insure Agile cross-team collaboration isn't inhibited by architecture changes.
Using BPEL to find issues
One way to help identify existing component issues that should be corrected in a cloud-based project is to look at the Business Process Execution Language (BPEL) workflow orchestration for current applications. An example is where two different functions are invoked by the same BPEL or where BPEL defines divergent reasons for doing the same thing in the same workflow. Either could signal a nonfunctional component alignment.
While SOA componentization can support agility through component reuse, it can also enforce rigid process relationships that will doom Agile development for the cloud. BPEL or workflow can signal issues here as well. If BPEL orchestration is sparse, it may be an indication that too much business logic is being written into components. This, according to users, is the primary way SOA componentization and reuse principles get off track.
Orchestration in the BPEL sense raises the potential impact of another kind of orchestration: the automation of deployment and integration processes associated with an application. The cloud often uses DevOps tools to deploy and integrate application. The development tasks associated with supporting DevOps properly can also identify componentization and agility compromises.
If component reuse is successful, many of the components of a new application should be already deployed for use elsewhere. When that's proven not to be true, it could be an indication that current components are too application-specific to meet even previous SOA componentization standards.
Circling back to agility
The collision of DevOps, SOA reuse, and Agile design makes it important to recognize that Agile development and Agile runtime orchestration are not the same thing. A component can be reused either by reimaging it or by using a common image, with the latter representing modern as-a-service design principles. Even state-of-the-art cloud design may not mandate the as-a-service deployment of components, but things are moving that way.
Arguably, as-a-service component design is what would make cloud agility differ from application agility or design agility. When conceptualized as services, components have the property of multi-tenant operation, horizontal scaling in terms of the number of instances to be run, and elastic load-balancing and state management. Most SOA designs are not authored to be used this way. When considering Agile SOA for the cloud, make looking ahead to making this as-a-service world your final requirement. It will save a lot of trouble later on.
About the author
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
Follow us on Twitter at @SearchSOA.
Architects' evolving role and Agile methodology
Agile development best practices for the enterprise
Agile methodologies and architecture meet head on