Last week's post on Agile & SOA has generated some great conversation. There is general agreement that Agile and SOA share values, particularly around the end goal of business responsiveness. The question though, is how to provide that responsiveness (velocity and flexibility), in a sustainable manner (architectural integrity). Themes that emerged in the comments were separation of concerns, increments vs. iteration, and the three C's: communication, coordination and collaboration.
Today, I'm pleased to add another voice to our conversation. Annie Shum, a leading SOA and technology thinker, was kind enough to share her views on SOA and Agile in an email conversation, with permission to post here.
In the first business-driven architect guest post, I'm thrilled to publish Annie Shum on Agile and SOA:
"Adding a bit more to the discussion but from a different perspective based on my favorite metaphor of SOA analogous to a set of architecture and urban city planning blueprints plus administration policies whereas developing software is more akin to building buildings, bridges, or other structures in a city.
The former is a meta framework where city planners, building architects, policy makers, construction contractors, government officers including zoning permits etc have to come together to create a master plan through collaboration & communication - all under some explicit as well as implicit policies & overarching governance. It's not about the city planners dictating individual buildings but more about the overall cohesion of the city: the neighborhoods/community planning including security (courts, police buildings, fire stations etc), education (schools, libraries) and recreation (parks, zoos etc). The relationships matter more than the individual structure to the city planners. Meanwhile, the contractors can go ahead and build the buildings according to their own business models as long as they comply with the master blueprint of the city planner office, the zoning laws, leverage the common infrastructure based on city standards etc.
To cut to the chase, that's what Agile vs SOA is all about. Historically, software development has been by and large project centric. To me most software development projects are still akin to "building little house on the Prairie". Whether you use Agile or waterfall approach has both pros and cons. Obviously Agile has a lot of compelling benefits (note: I favor Agile) but only work effectively if there is constant communication between management and developers as well as clearly spelled out accountability methods to manage rogue development. Above all, transparency is critical regardless what technique is used: agile or otherwise.
In a SOA shared service ecosystem, so long as the enterprise architects act as the city planners and work collaboratively with business process owners, LOB exec, software architects, developers, database architects IT staff, capacity planners, performance analysts, etc to create a cohesive set (maybe incrementally) of architectural patterns, blueprints, what services to share, what standards to comply, what policies to follow and to specify etc, then the software architects & developers are in theory free to implement their services (encapsulated by standards based interfaces, contracts and policies) and composite app using their technology choices and development approaches: Agile or not or more likely a mixture of agile and traditional method...
So it hinges on the SOA ecosystem cohesive architectural patterns, policies and blueprints that act as the beacon & "glue" for the enterprise. That's why reflective modeling is so critical: it's the closed loop modeling process from begin to end throughout the lifecycle of services that can guide this complex SOA transformation. Having a pervasive metaframework for modeling different aspects of SOA, I see Service oriented based modeling as the intermediary and the bridge connecting business & IT as well as connecting architecture patterns with software development."
Leave a comment