Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News New Resources for the Software Architecture

New Resources for the Software Architecture

This item in japanese

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:
1. An outline description of the software architecture, including major software components and their interactions.
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.
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.

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 case
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
Mike also gave some insight in building a strong business case by focusing on business processes.
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.

Rate this Article