Several new resources are available for the software architect. Simon Brown and Kevin Seal have made available a set of guidelines for creating software architecture documentation. Mike Kavis also put together a framework to help guide the architect in dealing with the change that new architecture can bring.
The purpose of Brown and Seal's Software Architecture Document Guidelines v0.1 is to provide:
Mike Kavis said "Most articles that I have read discuss two critical elements: the technology and governance. Not enough people are talking about change management." He used John Kotter's 8 steps from "Winning at Change" to show how architects can deal with the change necessary for Enterprise Architecture or SOA initiatives. Mike's 8 steps applied to architecture projects are
The purpose of Brown and Seal's Software Architecture Document Guidelines v0.1 is to provide:
1. An outline description of the software architecture, including major software components and their interactions.Each of the 15 sections of the document included a short description or examples of the content to be included in the section along with a checklist for the architect. The authors created the guidelines as part of a tutorial they delivered at QCon London 2008. The document is available in PDF form.
2. A common understanding of the architectural principles used during design and implementation.
3. A description of the hardware and software platforms on which the system is built and deployed.
4. Explicit justification of how the architecture meets the non-functional requirements.
Mike Kavis said "Most articles that I have read discuss two critical elements: the technology and governance. Not enough people are talking about change management." He used John Kotter's 8 steps from "Winning at Change" to show how architects can deal with the change necessary for Enterprise Architecture or SOA initiatives. Mike's 8 steps applied to architecture projects are
1. Build strong business caseMike also gave some insight in building a strong business case by focusing on business processes.
2. Secure executive sponsor and top level buy in
3. Create a Road Map
4. Communicate the Road Map
5. Empower Others to Act on the Road Map
6. Start small, deliver early and often (agile)
7. Expand, leverage reuse
8. Govern
We did not talk about SOA in technical terms. What we did tell them is that by leveraging a "new" technology, we could automate their entire workflow from contract to delivery without having to rewrite any of our backend systems. This new technology would allow us to connect their new web based systems to the existing systems through an "adapter". Of course, by adapter I mean services.By going through the business need for BPM, Mike's organization was able to get the business to champion the SOA and BPM initiatives.