Let's play a word association game. When I say "Architect" you say, what? "Buildings… Cities… Sky scrapers…?" How about "Data"?

More and more professionals who work with data are starting to see themselves as architects. A quick look in the dictionary shows that the title ‘architect' is aligned with the design of physical structures. However, a closer look into what it takes to ‘design' highlights the similar processes involved whether the medium is bricks and mortar or data.

As IT consultants it can be easy to see much of our work as mimicking the work of an architect. Both types of architects live in a world of creativity with several boundaries. Much like a big city architect tasked with erecting a sky scraper in the middle of a bustling metropolis, IT consultants are given complex business challenges and asked to create designs which meet client requirements. Building architects are trained to build structures that are up to code, yet meet customer demand; they must balance the desire to be bold with sensible design and the law. IT consultants look to create the fastest processing system while also adhering to the limits of the data platform and the constraints of best practices and data governance.

A key difference between an IT consultant's output and a traditional architect's is that the end result of a ‘traditional' architect's design is transformed into a physical, visible building while the end result for an IT consultant is most often an abstract, non-visible function or structure. This is an obvious, but critical distinction and it should lead IT consultants to understand the importance of architectural diagrams.

Data Architecture: More than a Blueprint

Since our product can't be seen from a car, or walked through, the importance of visually representing the construction of data is of crucial importance for an IT consultant. Like a blueprint, data architecture diagrams can direct the construction of the process, but whereas a homeowner can agree on a blueprint design and then walk through the structure and make tweaks here and there, an architectural diagram is the walkthrough for a stakeholder – they won't be able to ‘see' the progress as it is being built. Most of us include an architectural diagram as an appendix or add-on to a design document, but we should see the visual representation of data with the same importance as a blueprint – an architect doesn't start a project without creating a blueprint.

Since business requirements are captured within documents that can be filled with technical language, it is often difficult to ascertain the ‘big picture' and to really understand how data is stored/processed/changed within a system. Again, data architecture diagrams meet this need by providing a one page snap-shot of the business requirements, visually represented. Like the walk-through example above, a realtor who lists a home online can write out the dimensions of the room, the size of the lawn and the color scheme, but a customer can't really understand the layout of the home until the house, the lawn, the rooms are seen in pictures on the site. In the same way, business users and developers – even with pre-existing business requirements - may not be able to ‘see' what process/system is to be constructed without a well-designed diagram.

Once data and its storage/processing/changes are better understood, it becomes significantly easier to identify potential risks before there is a chance for damage. Let's use an example. Say there are hundreds of business requirements being used to create a web site which details a customer's shopping history from a certain website. At irregular intervals within the document, a requirement states that a particular database is pulled for compiling reports necessary for the site. What could be overlooked within the thousands of lines of uninteresting (let's be honest here…) text can be easily seen with a diagram. It's possible that after diagramming out the business requirements we see that one particular database being used for reporting will be overloaded by the current design. Even if this problem was discovered early on within the design phase of a project, it still adds unnecessary rework time and prevents a more efficient design from being created and approved during the appropriate phase. (Note: there are many different types of data architecture diagrams one could use, from the formal - like a data model/relationship diagram seen here - to the informal - like the free form diagram seen here. A full discussion of the pros and cons of each type of diagram would be out of the scope for one article.)

The distinction between creating a visible, tangible or ‘traditional' architecture and creating one that exists within servers or a system has far reaching implications for our roles as IT consultants. Understanding the criticality of getting data and business requirements mapped in an architectural diagram is essential – it increases the understanding of the team, the strength of the design, and the overall probability of success for the project.