Welcome!

Microservices Expo Authors: Liz McMillan, Pat Romanski, Elizabeth White, Mehdi Daoudi, Yeshim Deniz

Related Topics: Microservices Expo, @CloudExpo

Microservices Expo: Article

Who Really Needs a Blueprint?

Does the architect really need a blueprint? No.But everyone else sure does!

A few days ago we facilitated a passionate discussion on the subject of Blueprints (ah, the joys of an emerging market). The gist of the conversation was focused on deciding where limited marketing resources should be applied, and during that exercise a surprising insight came to us. It seemed so counter-intuitive at first, then as we kept exploring it became so blindingly obvious that we questioned our intelligence for not thinking of it before.

What was this revelation, you ask – and more importantly, why should you care?

An Architect doesn’t need a Blueprint.

Let’s step outside IT for a moment and use the analogy of a Blueprint for a building to illustrate this point, since no one questions the value of either an Architect or the Blueprint in that context. The Architect has the smarts; with years of experience they interview the client to gather requirements and constraints, show possible designs and articulate tradeoffs, and then eventually labor to codify the design decisions into a complex multi-dimensional Blueprint. If all goes well the client signs off and, unless there is a problem when the structure is being built or the client changes their mind, their job is done.

But the Blueprint is just getting started...now it gets handed off the general contractor, who in turn provides relevant pages to the subcontractors that do everything from excavating the foundation, to installing plumbing and wiring, to interior decorating. The general contractor also provides the Blueprint to the relevant inspectors, who reference the Blueprint as they audit the facility to ensure its compliance with building codes and other ordinances. And once the structure is completed, the Blueprint is provided to the party responsible for operating the building, where it’s consulted whenever a change is proposed or when trying to diagnose a difficult problem. In this context, it’s pretty clear that the while the Architect creates the Blueprint, they are the ones who use it the least. However, the Blueprint is essential to communicate what’s going to be built by a number of different groups, to audit what’s actually been built, and to serve as the authoritative reference when a change is proposed or when a complex problem is observed.

If we bring this back to the realm of IT there are strikingly similar parallels. We have an Architect assigned to design an environment to support a new application/business function, or perhaps to replace an existing one. Step one entails an interview with the business user or their proxy to understand the purpose of the system, and to capture requirements and constraints. The architect then does their work, selecting from enterprise standard technologies and assembling them in a manner that they believe will meet the requirements. They draw diagrams, create a document with cost and time estimates, and then go back to the business user for approval. Assuming that approval is granted, the service request is then fired off into the enterprise process for procurement, engineering, and system builds. Many different groups, many different processes, many dependencies – all trying to provide the system the business needs, but frequently ‘interpreting’ the request based on their view of the world and without a clear understanding of the impact of changes or delays in their work to the overall process.

In most environments we have seen, the diagrams and document originally created are filed in the appropriate repository but each group has their own documentation process and thus uses the original specification approved by the client as ‘input’ to their process. When it finally makes it through the QA/test function to production, the Operations team is given a handful of documents to keep track of (typically stored in different places), so they too create a document suitable for their purposes using ‘input’ from the others. Have you ever watched a group of young children play the game “telephone”, where a message is whispered from child to child? The final message rarely resembles the original. Is it any wonder that IT continually fails to meet business expectations?

Now to be fair to Blueprints, they offer a lot of benefits to the Architects as well. They provide a common language and template for communication that all parties involved recognize and understand. They also provide a great starting point when designing a new widget with similar requirements as one they created in the past. And they certainly help a journeyman Architect perform at a much higher level than they might otherwise, which provides both scale and consistency benefits.

But in the end, does the Architect really need a Blueprint? No. But everyone else sure does.

More Stories By James Houghton

James Houghton is Co-Founder & Chief Technology Officer of Adaptivity. In his CTO capacity Jim interacts with key technology providers to evolve capabilities and partnerships that enable Adaptivity to offer its complete SOIT, RTI, and Utility Computing solutions. In addition, he engages with key clients to ensure successful leverage of the ADIOS methodology.

Most recently, Houghton was the SVP Architecture & Strategy Executive for the infrastructure organization at Bank of America, where he drove legacy infrastructure transformation initiatives across 40+ data centers. Prior to that he was the Head of Wachovia’s Utility Product Management, where he drove the design, services, and offering for SOA and Utility Computing for the technology division of Wachovia’s Corporate & Investment Bank. He has also led leading-edge consulting practices at IBM Global Technology Services and Deloitte Consulting.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Microservices Articles
DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City. Digital Transformation (DX) is a major focus with the introduction of DXWorldEXPO within the program. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term.
As Enterprise business moves from Monoliths to Microservices, adoption and successful implementations of Microservices become more evident. The goal of Microservices is to improve software delivery speed and increase system safety as scale increases. Documenting hurdles and problems for the use of Microservices will help consultants, architects and specialists to avoid repeating the same mistakes and learn how and when to use (or not use) Microservices at the enterprise level. The circumstance w...
Containers, microservices and DevOps are all the rage lately. You can read about how great they are and how they’ll change your life and the industry everywhere. So naturally when we started a new company and were deciding how to architect our app, we went with microservices, containers and DevOps. About now you’re expecting a story of how everything went so smoothly, we’re now pushing out code ten times a day, but the reality is quite different.
Traditional IT, great for stable systems of record, is struggling to cope with newer, agile systems of engagement requirements coming straight from the business. In his session at 18th Cloud Expo, William Morrish, General Manager of Product Sales at Interoute, will outline ways of exploiting new architectures to enable both systems and building them to support your existing platforms, with an eye for the future. Technologies such as Docker and the hyper-convergence of computing, networking and...
While some developers care passionately about how data centers and clouds are architected, for most, it is only the end result that matters. To the majority of companies, technology exists to solve a business problem, and only delivers value when it is solving that problem. 2017 brings the mainstream adoption of containers for production workloads. In his session at 21st Cloud Expo, Ben McCormack, VP of Operations at Evernote, discussed how data centers of the future will be managed, how the p...
The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regu...
Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple cloud provider environments. Yet, despite this portability promise, developers may include configuration and application definitions that constrain or even eliminate application portability. In this session we'll describe best practices for "configuration as code" in a Kubernetes environment. We will demonstrate how a properly constructed containerized app can be deployed to both Amazon and Azure ...
CloudEXPO New York 2018, colocated with DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one location.
The now mainstream platform changes stemming from the first Internet boom brought many changes but didn’t really change the basic relationship between servers and the applications running on them. In fact, that was sort of the point. In his session at 18th Cloud Expo, Gordon Haff, senior cloud strategy marketing and evangelism manager at Red Hat, will discuss how today’s workloads require a new model and a new platform for development and execution. The platform must handle a wide range of rec...
More and more companies are looking to microservices as an architectural pattern for breaking apart applications into more manageable pieces so that agile teams can deliver new features quicker and more effectively. What this pattern has done more than anything to date is spark organizational transformations, setting the foundation for future application development. In practice, however, there are a number of considerations to make that go beyond simply “build, ship, and run,” which changes how...