James McGovern: Practical Guide to Enterprise Architecture, A
Scott A. Bernard: An Introduction to Enterprise Architecture: Second Edition
Jeanne W. Ross: Enterprise Architecture as Strategy: Creating a Foundation for Business Execution
Ralph Whittle: Enterprise Business Architecture: The Formal Link Between Strategy and Results
Steve Jones provides a succinct and rational approach to breaking large projects into smaller, more effective efforts by applying SOA on top of Agile methods. Essentially he suggests breaking down the components and services as work packages that are able to be completed by a small (4-6 person) team, and managing the work packages.
A simple, rational, and as he explains, a time-honoured approach.
My previous post SOA and Agile - Peas in a pod got me thinking a little more on some analogies, and about the up-front/unchanging reputation of traditional architecture practices in comparison with my view of architecture as a (potentially) very nimble and flexible process.
One of the problems with non-traditional (e.g. Agile) development methodologies is the human factor. The tendency for developers/designers to invest their ego into the software they are working on. For Agile to work you must be willing to separate your personal investment in your creation, assume that you don't know everything up front, the chance of change is %100, and that it's quite likely that you are going to have to toss a good portion of your effort away.
It makes me wonder (mostly, but not totally jokingly) if the best agile software developers wouldn't be Buddhist monks, with their four noble truths. In short: life is suffering; the cause of suffering is attachment; eliminate attachment, and you eliminate suffering. These guys are onto something.
In this regard, enterprise architecture and SOA could learn something from the agile (or a Buddhist) school of thought. We cannot invest ourselves too deeply in the perfect architecture. 1) it does not exist, 2) things change, and therefore architecture will change. That's life, deal with it.
Increased satisfaction and effectiveness of architecture and development efforts could be achieved if we bring the agile principles of acceptance of continuous change to EA and SOA. Architectures cannot flourish and be effective as solitary monoliths of unchanging perfection. Besides, if they were up-front perfect, what would architects do with themselves? Sit around a meditate perhaps?
Brenda posted about the compatibility of SOA and Agile, comparing them to apples and oranges. I'm not sure of the best metaphor to use, but in my opinion they're undoubtedly compatible methodologies.
It's human nature to want to 'waterfall' processes. From architecture to software design and development. EA, SOA and, of course, Agile, all benefit from an iterative and incremental approach. Another key practice I've heard applied to both is to, "do just enough, just in time" -- or just in time/agile architecture.
Amongst the strengths of agile methods are the strong assertion that you don't know all the answers up front, that you're willing to accept and embrace change at any point. These are excellent principles to apply to SOA as well, within reason. Assuming you're going to start from zero and work out a complete and workable architecture, followed by a representative development and implementation is probably folly.
Architecture, among other things, is meant to constrain and guide development. In this regard, EA, SOA and agile should be able to live together harmoniously as long as the architects and developers come to a pragmatic consensus about boundaries and collaboration. This means having a good working relationship between the two camps, and a good idea of the reasons and methods behind the respective schools of thought. This, perhaps, is the hardest thing of all to accomplish. It certainly requires a lot of trust on both sides.
The approach we've taken thus far is to have architecture define a set of well validated services, interactions and general interfaces based on our EA practice, which is directly traceable to business desires. During implementation we have used an agile methodology to actually construct the innards of the services, integrate, and to build human interfaces and detailed components of the desired system.
The architects take care to guide the direction, and assert control only over the critical (architecturally relevant) portions. Usually this means staying at a fairly high level of abstraction. The remainder (the details of implementation, integration, detailed data structures) are left for the designers/developers, and if they choose, an Agile approach. This works best if the designers/developers and architects will interact as the project proceeds to make adjustments and clarifications as needed. In this way the architecture, and the implemented system both come closer to meeting the true needs of the business in the end.
I'm keen to hear other opinions in this regard, as admittedly my SOA and Agile experiences are still quite new, and only partially tested in the real world.
