Being an advocate for IT Architecture & Design can be a little bit of a struggle sometimes, especially if engaging with start-up organisations, or any organisation fighting to become more agile, creative and differentiating. Sometimes, but not always, these organisations see Architecture & Design getting in the way and slowing things down. Mostly, this is caused by an individual or team of influencers having a poor experience with the classic “Ivory Tower” approach to Architecture (Tell you what you can’t do, but not what you can do).
I was reflecting on how experts in their respective non-IT fields handle “Architecture & Design” activities, and it appeared to me that most professions do at least some “Architecture & Design”, but the most practised have perfected the art of making sure the depth and breadth of design is in proportion to the needs of the design subject. Let’s look at some examples.
In the world of physical design and build, let’s say carpentry and joinery, you can see a couple of extremes of approach between a fitted kitchen and a bespoke, one-off piece of furniture. The fitted kitchen will typically (unless completely bespoke) be assembled from standard modular components (each built to a standard pattern). A kitchen designer will make the layout fit the constraints of the room and meet the customer requirements. Supporting infrastructure (wiring, plumbing) will also be considered and adjustments made (integrating the kitchen to the environment). There will be some limited scope for individual flourishes such as door design, colours, handles, work-surface, taps, appliances etc, but many of these changes won’t impact the foundations and core design, and can be changed on the fly, or made much later in the build process. If the Architecture (of the entire solution and how it fits in the environment) is not done adequately, or the design of the individual components and how they interact is not of great quality, the chances of a robust, easy to use, functional kitchen is low. Some of you may have experienced this in real life!
Now, if we look at the bespoke furniture scenario, designed and built in the boutique workshop, the approach and results may be somewhat different. Typically, concept, design and build may be undertaken by the same crafts person. Depending on the clarity of vision and complexity of the piece, the design may just be a series of concept sketches or evolved further into a full CAD scheme. The design process could also include building cardboard mock-ups or plywood prototypes to understand scale and proportions. These can evolve into patterns and templates that aid in the construction of the final piece. The crafts person is free to evolve and develop individual flourishes to the design all the way through the build process, taking advantage of features and blemishes in the raw materials to maximise the final effect. The final piece may have some subtle differences to the original design details foreseen but will generally hold true to the concept and vision, with design variations being taken to take advantage of available materials.
Having some experience at least of both worlds referenced above, I can see some strong parallels to various approaches to architecture, design and development in the IT world. The bespoke furniture piece and the standalone “App” or innovate prototype for a small start-up (that can be industrialised and replicated once adoption and feedback is understood). The fitted kitchen and the larger commercial off-the-shelf product implementation (or even a large-scale software deployment using open-source platforms and tools).
In both IT situations, the cost of failure from moving forward without some semblance of architecture or end-to-end design are far greater than in the carpentry and joinery world. Even the standalone “App” is useless unless connected and secured with other data sources (even a basic calculator app may have a connection to world currency exchange rates), and of course the user interface still needs to be designed. So, in this scenario, a basic concept and sketch is probably all that’s required. The more complex the integration and function, the more diligent the design process needs to be.
Larger complex enterprise IT programmes and projects really deserve more in terms of Architecture and Design, but this should still be in proportion to the scale, scope and complexity of the change, and consideration for the Architecture and Design efforts already undertaken in the supplied components should be given (e.g. re-design of the cooker, tap or basic 600mm under-counter unit is not required!).
At Mosaic Island, we’ve been using and advocating a pragmatic approach to Architecture and Design since we developed our approach within a highly marketing-driven environment in the early 2000’s. We have a range of techniques that allow delivery to move forward at pace while ensuring a balance of architecture and design in support of wider enterprise objectives. We have found these techniques to be successful in both agile and waterfall delivery approaches.
A key tool we seem to always come back to is the simple “Design Passport” – a mechanism to get the basic concept or sketch written down. For larger projects and programmes we would advocate a design strategy that captures all aspects of the architecture and evolving design as the programme progresses. For large and highly complex technical environments we have developed approaches supported by tools that allow highly developed organisations to move to “model-based design” rather than document-based design. Not every organisation will need this level of Architecture and Design capability – again, in proportion to scale, scope and complexity of change.
In the end, good Architecture and Design is about getting a product or service delivered that meets the total requirements of the customer or user. That encompasses time, quality, cost, utility and usability.