Enterprise Architecture

The art and science of creation

Today, the word architecture in the Information Technology arena is not always used in its correct context. As one of the silver backs I can remember when we used the word engineer as a freely as we use architect today. We had customer engineers, solution engineers, hardware engineers etc…. Some uses were correct and others were very loose interpretations of the term. Today we have information architects, solutions architects, network architects, voice architects and the likes of usability architects. Again, some correct, others, well, just good old marketing.

I personally take architecture very seriously.

The Webster’s dictionary that I possess at home states the following:

Architecture – The art or science of building; that branch of the fine arts which has for its object the production of edifices pleasing to a cultivated and artistic taste; construction.

How real is this? Architecture is the marrying of art and science. The production and building of edifices (technology) that is pleasing. Pleasing becomes the operative word here. Just because something is built does not mean it is architecture. It just means it was built.

Architecture is like so many other borrowed terms we use in Information Technology, and made our own. This one in particular is of special interest to me because I take it so seriously from its purest beginnings and meanings. We stand on the shoulders of giants rings so true in this arena.

Some of my previous posts talked of the IT Stack and its importance for sound design. Enterprise architecture follows many of the same truisms. The IT Stack becomes what a draftsperson is to an architect. The architect has a vision and translates it into real-world designs. The architect then works with the draftspeople to iron out the real world forces. When we were all called engineers, I baulked because too many engineers only know the known and do not push the limits. The architect starts with art in mind and then transfers it to real engineering problems to be solved.

The graphic above demonstrates the 4 key domains for enterprise architecture. Some enterprises will have more domains and that is just further fragmentation of the arts and sciences. The department of defence has taken a much deeper view, but if you were to step back the 4 main domains this post will encompass the others in some form or other.

The graphic has the business domain as its center and I believe it is the lynch pin that binds the other three. With the business domain of “why”, the other domains of “how” become support players to the main event. Even the best historical architectures had an underlining purpose. These edifices of wonder were able to solve the need with special designs. The pyramids, the coliseums, the churches and the grand bridges that have stood the test of time have also stood the test of good taste. I remember standing in the Saint Michel castle in France and witnessing the formidable architecture that was over 1000 years old. The basement did not leak, the walls were not cracked and the roofs have sustained the mighty gales of the English Channel. In its 1000 plus history the walled city had never been breached and the trained eye could see the advancement of technology in the buildings while never giving way to the sheer beauty of its architecture.

In modern times we have such wonders. Time will tell which ones were true to real world realities and have lasting artistic value.

The information technology craft is new and as such is prone to flux and at times chaos. Now is the time to gain back some creditability to move us forward. Many believe the pace of change has been too fast. I could not disagree more. I feel we have been hindered by technology business models that have rewarded the quick and easy and not the long, difficult, right way.

I was speaking to our owner regarding the “cloud.” Our owner is a self made multi-millionaire and a companion of the order of Canada. He has prided himself on honest, pragmatic business. He has been rewarded for his principals and he is also the holder of several key transportation patents for his forward-thinking designs. By his own admission he knows nothing of computers. After about a 10 minute explanation from me comparing the “cloud” to 3^rd party logistics companies he started to understand. That analogy is the best I could come up with where you do not own the assets but leverage them. My owner had a pregnant pause for about 20 seconds. This is a long time for a man of his drive and passion. His response was short and very direct. The reply was “what took so long.” For him it was so clear, yet, we as an industry have not been able to exploit it and move it forward yet. The answer to that riddle took a little longer. Over several beers he came to realize that the technology sector is not rewarding leaders of technology but rather managers of business. The business model is sound but the debates over what is or what is not the “cloud” is preventing us from moving forward as a whole. This is not good business and even worse technology. His response was, you had better agree on that you need a road and that everyone has to be on the same side of the road. He brought our problem back to his transportation world.

This is a long pre-amble to state that without a real business reason any architecture is strained to deliver value beyond its artistic impression.

Business Architecture

This is the core domain and it answers the biggest question and that is the “why”. The next area of concern for this domain is what, who, where, when and which information is relevant. The process thinking person is well suited here. The business domain is about making the logical connection between business information and the processes that drives it and relies on it. A good business architecture model will drive all the other models and be used as the referential checkpoint for all the other domains.

Be careful of the process purist. These individuals tend to pave the cow path and have data needs that will strain good data governance and control. The process should solve the business needs in the fewest possible steps, in the most secure way, with sufficient oversight to be managed and to be improved. All architecture domains need to be built to be built upon.

The strategic business view needs to be broken down into tactical components and then into operational elements.

The business domain will map the people, their processes, and the tools required to complete the business requirement. I am a visual person, so I will draw many process and mind maps to isolate the patterns for improvement and critical success. The information going back to the organization must be presented in the form the business can understand. The artefacts also have to serve as the core building blocks for the other domains. Constant checkpoints from the other domains have to be made to ensure the business domain is adhered.

Technical Architecture

Some groups will call this domain the infrastructure domain. I am part of that group. This domain manages and controls the hardware and software of the organization. Along with this it will adopt secure methods for all other elements of the solutions.

The biggest and most valuable artefact from the technical architecture is the blueprint for the functional and non-functional requirements. I pay special heed to the non-functional requirements, for these are the ones that tend to get overlooked and cause the greatest strain during implementation.

This domain also has a large role to play on cost minimization, technology blueprint adherence and the proper implementation of standards. A good implementation of the technical architecture will become the building blocks for other domains and other business solutions. This domain should focus on flexibility and reusability. The patterns derived from this domain are almost always used for other solutions. This domain also provides a strong blueprint that can be used for all following elements, especially security.

Solution Architecture

Solution Architecture is the glue that binds the data models to the technical models to deliver the business model. Some groups will call this domain the application domain. If you are new to an organization and their enterprise architecture group, then make sure you get their taxonomy clear. Some groups can be very particular on this.

Solution architecture starts to make patterns from the business model, to feed the data model, and will be supported by the technical model. The focus here should be on component modeling and the carving down of major functions into smaller more reusable elements and modules. Strong adherence to security, interface design (internal and external), data connectors, messaging, auditing, logging and version control become paramount. The project manager and the business sponsors need to conform to the business model and the non-functional and functional requirements. Scope creep can be a real issue here and controls need to be used to keep the team focused.

This domain will also be faced with the greatest iterative steps and the greatest use of lifecycle management. The users will be playing in this backyard with little or no expertise and it becomes paramount that the solution architecture stays true to the business architecture. When there is confusion, a checkpoint must go back the original model to ensure the business needs are being met. At times this domain can get enamoured with scientific or artistic discoveries. The architect is required to keep the final vision in focus and not the current unforeseen discovery. This is a real discipline and the best solution architects have a strong eye towards delivery rather than discovery.

Data Architecture

This is likely the oldest of the disciplines and is the genesis of many other methodologies. It is computer science 101 and is the most abused of the disciplines. The advent of spreadsheets and personal databases has muddied this craft. There are many who think they understand data models but the ones who really do get frustrated by the poor data models and database implementations of the others. Another issue that arises is the forced use of old techniques when newer more effective approaches are warranted. Modern databases support auto indexing and the old technique of composite keys only burden the systems for downstream business analystics.

The conflict has always been present between the data purists and the process purists. The fact remains they must be in balance and work complimentary.

Data should be modeled to reflect the process’s use of the data and yet still be able to convert the data into information. I have seen overburdened data models that span thousands of tables where similar applications patterns have used 100 of tables. The pure data architect can justify both but only the enterprise architect can validate which ones solve present problems.

Modern databases and database options need to be exploited in a positive proactive way. Privacy and security issues can be enhanced within this domain for a more robust overall solution.

I really enjoy seeing the application domain come to life within the data model. Many of the business model patterns can be tested and vetted with good data architecture. For in the end if it is not stored it does not exist for the other domains in a complete enterprise world. I know some knowledge management folks have just cringed. Data architecture takes into account all structured and unstructured data to complete the information picture. Once these patterns are complete and available they become a source of knowledge.

In conclusion

Without architecture we have form without function. With good architecture we have function with form that is pleasing. We have all witnessed good architecture even though we may not recognize it as architecture. To some architects that is the highest compliment. I am in that camp. When it works in its simplistic form to solve the most complex of problem, the Architect has successfully created art from the sciences.

An architect’s vision without execution is just a drawing. With execution come future patterns to be used by others to further the craft.