Agile Architecture is About Technology Practice

The cost of a bad design drawing starts at 1000 words and grows insanely rapidly. This article, the second in a series aimed for syndication via Shopventory.com, explores the initial planning stages; specifically, developing blueprints and roadmaps.Pictures are supposed to be worth a thousand words. I think this means many, many words are required even to attempt replacing a picture. Especially a nice one, like kids or a kitten or something. Nuance, etc, etc. When it comes to technical drawing, and especially technical architecture I've found an interesting twist on this --

An architect needs walk the line between practicable --I know it can be done-- and remedial --it spells out too much, if the developers don't fight you management will. This is done by using accepted and proven but somewhat general patterns. The architect guidelines like "put the files that read data here and the ones that make web pages over here" as well the more usual "We'll have an F5 passing web-pages to a bunch of servers, blah blah bling." Generally, these take the form of a set of assumptions made within the context of solution proposals. Once these have been accepted (or accepted as assumptions, at any rate) the project team then uses them cost, schedule, and otherwise plan.

So, all that plus gobs of diagramming this weekend got me to thinking - I know I've created a really bad drawing when I get a thousand words deep in the meeting where I've presented it and we're still talking about what I'm trying to depict.

Our rule is for most technical drawings to describe a single thing - ideally, the minimum detail needed to make a single clear and unique contribution to the set it will join.

The last part is especially tricky - it means this: suppose I have one set of drawings the show our systems in relation to vendors and other external technology partners (I do!), and a completely unrelated set set describing how our new Near-Real-Time data-processing back-end works (also true).

Clearly, there are plenty of exceptions but usually it's a time-sink a waste trying to draw all aspects of a problem into a single context.  Even when it can be done the result is often confusing.

Sometimes the places where you have different sets reflecting a common application different ways can be confusing.  Our answer?  Don't worry about it.  In general and where possible our practice recommends ignoring this problem, where possible. This may sound counter intuitive however the SMEs who do the real heady work to build and maintain the cooperative parts of your complex system will usually coordinate directly with each other to handle the detail of their coupling.   While the project clearly has a duty to capture this material, it is rarely helpful for a systems' or enterprise architect to attempt to capture specific details in project artifacts.

Other times, however, that's exactly what your architect does for you. Take for example, a large enterprise where many autonomous technology platforms many be maintained by different teams, each supporting different aspects of your business. Here, the architect (in fact, the architecture practice) has special responsibilities in terms of keeping a master application level set which keeps a "one true" vision for the application or technology portfolio team. This not only keeps a team of architects on the same page for consistent level of service across an architecture practice, much more importantly in enables the team supporting the application to stay aligned with each other as changes affecting their work are planned. As a final side benefit  when and architect provides application level blueprints to the team that maintains that very application, inadequacies related to that architects understanding of realty come quickly to light.

For a technical drawing to be effective it's got to communicate more effectively than can be done watching video or reading source or docs.  This is easy to do if you don't confuse people too badly when presenting them with new ideas, to which end we offer this advice:

  1. Keep it simple.  Make lots of drawings, not complex ones.
  2. Keep it consistent.  It's fine to have different sets that would not make sense if taken together, however if you have lots of teams, architects, or both consider application level blueprinting also.
  3. Is it clear?  Obviously, answering this correctly consistently this isn't simple.  Without belaboring the each of the obvious and extremely critical activities such as peer and stakeholder reviewsone thing I often find useful is to to show my work to someone I don't expect to understand it and ask what it looks like.  This often points out where I have two or three drawings that need to be separate so that each key concept can be  properly splayed.