|Software Architecture and
Agile with VAP: Getting Past "But..."
Our Getting Past "But..." executive report covers two essential areas:
These map roughly to the first and second halves of the report, though we encourage those interested primarily in the material in the second half to also read the first half. What follows is a brief outline of the contribution of these two parts of the Getting Past "But..." paper.
Innovation and Architects
Innovation is rampant, and clearly companies big and small are innovating apace. At the same time, many companies are disappointed with the return on their innovation investments. Industry incumbents are adapted to the status quo and defend their inertial tendencies with “but..”: but we aren’t chartered to do that, but that’s too risky, but our customers aren’t asking for that, but that would cannibalize our market. Focusing on immediate releases and incremental improvements, thwarts competitive landscape reshaping innovation which then tends to come from outside, often from start-ups.
Getting past “but...” takes a shift in attitude. It is true that this shift is fostered by empowerment, with an innovation culture established by top management. Google is the prototypical example there. It is also true that the shift can start with the individual. The creation of masking tape (the 3M story starts around minute 21 of Scott Berkun's presentation) is just one example where the inventor used his own initiative and limited budget to fly a skunkwords project under the radar. We need to recognize that generally there isn't a shortage of ideas. And, in aggregate, there isn't a shortage of willingness to take risks—witness the number of failures, including startups. What we need are more effective ways to get good ideas on the table, sift for those that make good business sense because they create high customer value that can be used to build differentiated identity and strategic advantage in the industry, put them through early, quick and cheap failure/improvement cycles, and get more and more talented peoples' heads in the game to build the system.
Our Getting Past "But": Finding Opportunity and Making IT Happen report speaks to role and process changes that empower design teams to create a new competitive basis through differentiating innovations. You can download a complimentary copy from Cutter Consortium at http://www.cutter.com/offers/findopportunity.html.
In this paper, we take the position that architects need to be part of, if not lead, the innovation team. The architect's role is to help the business identify opportunities to create value through capabilities that technology brings to the table. This leverages the unique perspective of the architect into technology and the organization's technical capabilities, but it also leverages the architect's unique skills in system thinking and modeling.
VAP and Scaling Agile
VAP (the Visual Architecting Process) is all about being agile even when the complexity of the system, and the organizational unit(s) building it, demands just enough upfront design—for example, to launch concurrent agile teams. What VAP emphasizes and enables is iterating on requirements and architecture, with intensive stakeholder involvement as pertinent to the quick cycles, so that in early agile cycles key system concepts are “built” using the cheapest design medium—which might be code, but often is sketches, and as the use and design concepts mature, more precise, careful models. Of course, VAP is also applied during coding cycles, but for complex systems, early VAP cycles use the cheapest possible artifacts (e.g., models and prototypes) for learning quickly about stakeholder value and architectural challenge. This concurrency, together with the principle of stakeholder involvement (including but not limited to end users), is a major value and contribution of VAP.
We write about JEDUF and agile architecture in the Getting past But paper. The content of the report is so important to the conversations we're having, to the challenges of organization after organization as the hype around agile pushes larger and larger projects to experiment with agile development. As we do so, we need to leverage all the lessons of our histories creating complex systems, as well as the lessons and values of agile development, to adapt a process that works for concurrent development of complex systems.
This synopsis derives from writing in Ruth Malan's (almost daily) architecture journal.