The age of the monolithic enterprise IT structure has been over for some time
-- now it's just about choosing the right nimble technology strategy. Do you attempt
an SOA implementation? Do you adopt Agile methodology for internal application
development? Or do you commit the unthinkable and create an unholy union of the
two, giving life to "Agile SOA?"
While the development and architecture camps might seem far apart, Agile SOA
isn't quite the voodoo it appears to be. Both sides have the same ultimate goal
-- to enable the business to change fast. SOA provides a flexible architecture
that enables IT to support business change more nimbly while Agile methods enable
faster development and deployment of software. Agile methods and techniques
go far beyond just building business applications. They can also evolve SOA
architecture and components from the highly complex, highly risky and insanely
expensive deployments they are perceived as today to something more palatable.
Agile techniques and strategies are designed to improve simplicity without
sacrificing functionality or flexibility, manage risks and abate costs. But
to adapt the Agile method to SOA, you need to meld the methodology to architecture
-- heresy to some, but perfectly sensible to those who understand the value
of Agile.
To the Laboratory!
SOA is more than an IT-only initiative. It should be driven, justified and
implemented with the business and requires close collaboration, much like any
joint-business venture. This collaboration between IT and the business at-large
is a basic tenet of the Agile approach as well. Architects should steel themselves,
however, as businesses, driven by market forces, want change now. SOA, however,
requires upfront, well thought out work. This requirement for change "now"
is why SOA implementation needs to unfold strategically and tactically at the
same time.
Igor, Bring Me a Brain!
Strategically speaking, you need a roadmap with some amount of infrastructure
in place and an idea of what applications will be deployed first. But just how
much infrastructure should be implemented before you start reaping SOA benefits?
What is the tipping point if SOA benefits can only be achieved by deploying
applications that use it?
To reach this tipping point, you need to establish the minimum foundation for
SOA services, specifically the services that implement architectural patterns
not driven by the business. These are infrastructure services such as security,
messaging, and interface (e.g., SOAP, WSDL, JMS, CORBA). This foundation dictates
the ability to cope with business changes and refactoring applications as the
enterprise moves towards SOA maturity.
-1-