The Architecture Journey
In an Organization, there are usually more than one computer systems connected to each other via computer networks. In a networked corporate environment you will find two types of computer systems: clients and servers. Clients usually referred to as Desktops, interact directly with the user. Servers are usually maintained by the IT department and most users interact with the server capabilities through their client desktops. A simple example is storage of a file on a network file share, a functionality provided by a server.
These clients and servers form an ecosystem. In a small organization maintaining this ecosystem is not difficult. Each client usually contains a number of locally installed applications that help the user to perform their business tasks. Information can be shared manually or through a network file share. However in larger organizations the number of desktops and applications that supports the business increases and so does the complexity in managing them. Complexity in sharing of information also increases. A quick analogy would be the difference in managing your house versus managing the city.
Computer system Architectures exists to provide coherent structure in this ecosystem, much like a building architecture provide the guidance on how the building should look and what features it should provide (number of bedrooms, bathrooms etc).
In the course of running your business, you are likely to have come across the terminologies: EA (Enterprise Architecture), SOA (Services Oriented Architecture), Application Architecture, Technical Architecture and Infrastructure Architecture (there are many other variants, but most will likely map or relate closely to one of the five I just covered). Why are there so many Architectures and how do they relate to each other? The figure below provides a quick snapshot on how they relate to each other. Note: it is very common for large organizations to also have an information or data architecture, security architecture etc. For this article, we can assume that these architectures are embedded within Enterprise Architecture or SOA.
Let’s start from the bottom of the stack - Infrastructure architecture is usually associated with the “plumbing” of the systems. They normally deal with network topology, identity management, server management and security.
Application architecture deals with the structure of custom and commercial off the shelf (COTS) applications that provides specific business functionalities. End users perform their business tasks through the use of these applications.
Technology architecture usually provides specific technology and product guidance for an organization. This architecture requires a lot of governance. It exists to increase the predictability of system roll out and it is usually done as part of a cost reduction. Minimizing the technology choices reduces complexity and chance of failure. This is similar to restaurants. Each restaurant will have a menu of what it can provide. It is not practical to have a very much wide variety of choices. However as a side effect, this may hamper innovation from newer technologies. Effective organizations have investments and processes in place that allows new technologies and business capabilities to be piloted and incorporated in a systematic manner into the Technology architecture.
Service Oriented Architecture (SOA) is a model or a pattern on how business functionalities can be exposed and used. The main attractor to SOA is the ability to provide modular organizational capabilities, allowing the system to be more flexible. By providing better system flexibility, the organization can be become more agile, because it will be easier and quicker to compose new capabilities. A simple analogy is to imagine that you are building a new house. To get electricity, clean water and sewage all you need to do is get an electrician and plumber to make the necessary connection to the street outside this new house. You don’t need to know where or how the electricity and water is made available, just that it is there and it is provided within a certain standards. SOA is essentially trying to mimic this in the computer world, allowing you to build new business applications by leveraging existing business data and processes quickly and easily. To make this happen, the systems from various vendors needs to agree on certain standards for communicating and exchanging information, the Organization must also have clear knowledge of their core business capabilities that can be used as a foundation. Microsoft currently spends a lot of effort to ensure that our products and technologies adhere to open standards, we compete on providing the most effective implementations and tools.
Enterprise Architecture (EA) is usually the most complex after SOA. One of the main reasons is the breadth of coverage. Effective EA will usually cover across an entire department, organization or even multiple organizations that belongs to the same holding company (although a much more common scenario is within the department or organization). In the discussion with respect to EA, you may have also come across the term Architecture Framework such as Zachman framework, US DoD framework (DODAF), Federal US Federal Architecture framework (FEA), UK Ministry of Defense Architecture Framework (MODAF), and the list goes on. In a very simplistic description, architecture frameworks are used to provide a consistent mechanism to document and communicate system architecture. It is important to establish a consistent framework within the enterprise to reduce misunderstanding on terminologies and views.
Hopefully the very quick overview on the five architectures helps clarify what they cover. The more interesting question is “do they really matter?” Having worked in a number of large organizations, I have seen how easy it is for centralized architecture groups tasked with EA or SOA to become isolated and drive policies that is not necessarily practical or in total alignment with the organization or business objectives. A recent working paper by the MIT Sloan Center for Information Systems Research https://web.mit.edu/cisr/working%20papers/cisrwp359.pdf provides interesting findings on the area of EA. One of the interesting topics discussed is the concept of Architecture maturity. The study found that most companies go through four stages of architecture maturity, from business silo through to business modularity. Business silo means each business unit will independently develop and maintain its own applications. Business modularity means each business unit core processes and capabilities are available in a modular fashion such that it can be quite quickly assembled to create a new business capability. There are three very interesting points covered in the paper that I would like to draw out:
1. It is the journey through the stages that matters most. They found that most organizations will not succeed in trying to jump stages too quickly or skip stages. This is similar to having a 13 year old child attend university level classes; only in very few cases can we expect the child to grasp what is actually being thought. Not all organization needs to be at the business modularity stage. It is far more important for the organization to learn through the journey and discover what and how technology can be infused with business direction to deliver the required capabilities.
2. As companies go through the journey, those with successful EA has been found as the result of the CIO having a good understanding and influence of the technology and business. In the businesses they have studied, the CIO usually carries another business role.
3. Business modularity stage is essentially what SOA is trying to provide. This architecture maturity model and the two items above really help explain why SOA is still not a reality in most companies. To deliver an effective SOA, companies need to be at the right maturity stage.
Recently I came across a very interesting quote by Brad Mercer from MITRE in his presentation “If you don’t control the Architecture of your system then that Architecture will control your system!” Imagine if you are the mayor of a city. If you do not provide a plan of what type of building should fill up which area then the population will determine it for you. Enterprise Architecture is the same, if you do not control it, it will be determined by the various projects within your organisation.
You may have heard of Infrastructure Optimization mentioned by Microsoft people. This is an initiative Microsoft has undertaken to classify the maturity stage of Organizations based on the work done by Gartner and MIT. In the Microsoft Infrastructure Optimization stages, there is specific classification and guidance on the initiatives organizations can undertake to move their maturity stage. More information for IO can be found here: https://www.microsoft.com/io
Microsoft Services has a core mission to ensure our customers and partners derive the most benefit from Microsoft products and technologies. Microsoft Consulting Services provides guidance and assistance for organizations in areas of Architecture and, application and system design. Microsoft Support Services provides assistance in IT systems management and product support. The Services organization is a relatively small unit compared to other outsourcers and consulting firms. The aim is to transfer knowledge into our customers and partners so they can become more effective on Microsoft products and technologies.
Most of Microsoft products are designed with easy to use wizards that allow small organizations to quickly learn and deploy these systems. Unfortunately in a more complex environment this becomes the problem point. The barrier of entry to deploy a technology solution is relatively easy that most organizations do not appreciate the complexity involved in planning and designing for the larger organization. It is important to ensure that these are considered up front.
As mentioned earlier, it is the journey through the architecture maturity stages that really matters. Microsoft Support Services can help your IT professionals become more efficient in managing the systems within your organization. This is in essence helping create a solid foundation to ensure that your desktops can be rolled out and managed efficiently. The servers are up and running. As business leaders you can be kept up to date on how your systems are performing.
One of the key areas that Microsoft Consulting Services can assist you is in analyzing and planning of your systems across the organization. Microsoft Services Business Architecture (MSBA) is a framework that has been developed over a number of years that has helped businesses rationalize their portfolio of business applications and better understand where to direct IT investment to receive the best ROI. By engaging Microsoft Services early in your journey, you will have a partner that will help you create a solid technology platform and also help you to navigate through the maturity stages. The following diagram shows one example output from the tool used by MSBA. The border color indicates the current performance (red = low performance), the fill in color indicates the importance of the business function (red = high value). The glyphs (black colored shapes) show the projects and/or initiatives that are currently planned to handle this specific area. From this small example we can clearly see where overlap of initiatives is occurring.
These types of exercises will help provide a clear picture of which areas will require attention.
