All Things Architecture Blog
Neal Ford and I recently recorded a video series from O'Reilly titled "Software Architecture Fundamentals" where we both talk about all sorts of cool architecture topics. One of the overarching memes within this video series is architecting for change. It is a difficult concept to grasp, particularly when you consider that one of the common definitions of architecture is "something that is really, really hard to change". That said, there are in fact several techniques you can use to help facilitate architectural change within the organization.
Last month I wrote an article for NDC magazine titled "Architecting For Change" which summarized some key techniques you can use for making architectures more agile. You can download a copy of the article here:
The basic techniques for helping to facilitate change within an architecture are as follows (most of these are discussed in the article):
- embrace modularity
- choosing an abstraction
- leveraging standards
- creating domain-specific architectures
- creating product-agnostic architectures
While all this sounds good, keep in mind that creating agile architectures come with a price. You pay for agility with decreased performance, added complexity, and increased development, testing, and maintenance costs.
I often practice, speak, and write about what I like to call the "Three C's of Architecture". These are as follows:
Communication is all about effectively communicating idea, concepts, issues, and solutions to stakeholders. By the way, stakeholders include anyone involved or interested in the project or its outcome, including the developers. For example, how many of you generate lengthy Word documents or email architecture decisions? Guess what? Those are most likely ignored. As an architect, the most effective way to communicate you ideas is using a whiteboard in a face-to-face meeting. Communication is all about how effective it is.
Collaboration is all about getting stakeholders involved in the architecture process and solicit ideas and feedback early and often. Notice the key words here: Solicit ideas early and often. Too many times architects sit there and wait for feedback from stakeholders. No, no, no. As as architect, you need to go out and solicit those ideas. Generally speaking, people will either agree or disagree with your decisions, but they will not approach you directly - you need to go to them. Do this early in the architecture process when things are easier to change, and do it often. This one pays off in spades. Trust me.
Clarity is all about articulating your architecture solution in clear and concise terms as appropriate to each stateholder. How do you communicate your architecture? Do you have a always-ready architecture presentation available for each type of stakeholder? If not, this would be something to strive for. The ability - at an instant- to describe *concisely* your architecture within the right context for that stakeholder at a moments notice is truly the mark of a successful architect.