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.

The case for blade centers

When it comes to blades you have to realize of couple of baselines. The first is that you must understand the value of virtualization. The second is that you have a long term view of your world.

So now that we have established the value of the baseline, you need to understand the two main types of blade setups. The first is many applications on one blade center and the other is many blades servicing one application. The latter is way kewl and is what we use to call “grid computing”. That buzzword has fallen by way of the “cloud” and other similar useless marketing technical terms. I will focus this post on the many applications on one blade center. Please read my post on consolidation. I am even using the same graphic for it is that similar. I am also lazy and graphically challenged.

In the past when you had to replace a server or had to buy a new server for new applications you were forced to use a crystal ball. Yes there were many tools to aid you but in effect you had to estimate what you were going to need for several years. In the first years the computer is oversized and underutilized over time the server starts to get utilized as per the requirement and without due diligence the server will become overworked and over utilized. The roller coaster effect takes over. This is the reality faced by most organizations.

The advent of blades allows you buy as required and expand as needed. The initial costs of the infrastructure are high but you can add server instances in places where it would have been tough to get funding. Overtime the cost per server is dramatically lower. Do not underestimate the value of this. It is also a caution to prevent what is termed “server crawl”. The proper implementation of blade infrastructure will reduce more costs than just the hydro and air conditioning that everyone is talking about. It gives management and extreme flexibility and a pay as you play approach.

By using a hypervisor you are able to adjust the supply to the demand without the long processes of procurement and implementation. Benefits of backup and system management now become more manageable as well. The big win, regardless of the marketing hype is that you can actually think big, start small and scale fast.

On a vendor note, be careful of the hype. Deal with vendors that know data centers and that have blade technology for your environment. Some manufacturers are for the many blades to one application model and others are for smaller shops that will not expand beyond the one blade center. Know your business problem before you buy and commit.

Currency Exchange

The concept of currency exchange is as old as time. However, it is not about the currency it is about the exchange. Before we had currency we still had exchange. Some would argue it was better before the advent of the money makers.

What I find so difficult these days is that we have all forgotten about fair exchange. The recent demise of our great, or not so great, manufacturing and finance giants says more about bad business than about some sudden change in the world.

When did making a good product, at a fair price loss to corporate management? I must not have gotten that memo. Oh wait, it might have been an email disguised as corporate direction. All kidding aside this is a serious issues and one that affects us all and especially us in the Information Technology field.

We do not always deal with actual currency but we trade with other currencies every day for most every decision. I build trust and relationships with the same respect a farmer does for his crops. I know that if I follow the process respectfully and I watch the crops to ensure no weeds, bad soil and such disrupt the planting then I should be granted a good crop to barter for other needed things.

This takes the shape of having people trust you when you say your project will be completed on time and on budget. In the event of slippage you may have to give up some of your non-cash assets to offset your project issues. This is not a light issue. I am astounded at people who just come up with dates as a placeholder and then say “oh well, missed another one”. These are the same people who whine “why are we not respected?” What did you do to garner that respect?

I am a senior Information Technology guy who has built a career fostering and building relationships. In fact I take great pride in them. In doing so, I have been able to exchange with these relationships things far more valuable then currency. These relationships have allowed me to very successful and to provide many rewards to the other parties in these relationships. It is a constant spending and saving exercise.

I have a penchant for seeing dumb people and bad ideas. When faced with this I get very agitated and somewhat cold. I make no apologies. If you profess to be in my craft you had better be prepared, be focused and be knowledgeable. This is not a challenge but a position of what I call mutual respect. I give you the respect of listening; you may want to give the respect of speaking respectfully. If you think a currency exchange will right this wrong you are sadly mistaken.

If you are a young Information Technology professional and you are starting out in a new position this condition will arise. One day you are going to witness your boss having a social meeting with another department head or a vendor. This can be viewed several ways. The first is of envy and you think “must be nice” the other more pragmatic way is “what are they talking about and how can I learn”. Now if your boss is the laughing stock of the company, the former response is likely valid. However, if your boss is highly respected you are likely witnessing a valid currency exchange. What you are witnessing is the natural give and take of negotiations. Most negotiations are built and over before the formal process begins.

This currency exchange can be between family members, lovers, friends, vendors, suppliers, customers and the like. If all you have is money to exchange then your relationships will be short lived and not very meaningful. It will be fast food approach to life and business. Rarely, in a professional world does the one with the money wield the power. Typically in the technology field the one with the knowledge is in the stronger position. Good business executives latch onto this and make sure there is more than just money in the exchange. Sadly as I look around, I see the old trappings of perceived wealth abusing the hard working. This will end, but it will take everyone remembering a fair exchange is derived from trust, respect and grounded in a common valued system.

You might be asking what spurned/spurred this email. Well it is like this. In the scenario above my new hire to our team did not take the time to learn what relationships I had built and as such destroyed the working relationship between our firm and three of our trusted advisors. One is completed lost and only my personal friendship is left. That one is a great loss to our firm. The second was easily explained and the third with be like the first. I will be able to sustain the third but only through friendship. The real loss here is that the individual still has not learned the value of the real currency exchange. One might asked why they are not fired. Sadly, spineless Human Resource departments prevent the right thing from happening. The only saving grace is that since my new team member will have it more difficult to complete their tasks with these advisors absent makes a good case for poor performance. It will be long road for us all since the basic rule of relationships was lost.

That is why in the Information Technology field some users and departments get things done ahead of other ones. Chances are an informal currency exchange was being adhered to and that is not a bad thing.