The Enterprise Technology Architecture, Part 3

In technology, just as in business in general or even life, there are risks that we all take.  Whether it’s skydiving, investing in a new startup or implementing new technology, there are always risk that need to be evaluated and weighed.  Each area of society has it’s own specific risks, and within the technology field, it is no different.  Risks that are common with technology tend to fit into these categories:

• Scalability – Will my technology be able to handle the scope that I need now as well as grow to fit the scope in the future?
• Longevity (Vendor Defocus) – Will my technology continue to be efficient and supported in the future or will it need to be quickly replaced by new technology?
• Failure to meet Expectations (Technology Death) – Will new technology I acquire actually meet my needs?
• Lack of Support  – Will the vendor/developer be able to support my needs?
• Lack of Expertise – Are there resources available to acquire which can internally support the technology for the long-term?
• Cost of Technology – Will the cost of buying and using technology becomes unaffordable?
• Data Integrity & Security – How do I keep my data safe and prevent data corruption?
• General Technology Security – Aside from data, how do I keep the rest of my technology secure?  This includes malware and viruses.
• Redundancy – Do I have the necessary backup systems in place to keep my business functioning?
• New Technology Adoption – How do I know when to implement something new?  What will be the positive and negative outcomes of the adoption?

As I talked about previously in How Do You Adopt?,  the adoption of innovation breaks down into 5 basic categories:

1. Innovators – 2.5% of the population.
2. Early Adopters – 13.5% of the population.
3. Early Majority – 34% of the population.
4. Late Majority – 34% of the population.
5. Laggards – 16% of the population.

As pointed out by Mike Blechar of Gartner, the technology risk level is directly dependent on the type of adopter involved (Blechar, 2006). This is also directly related to the vendor from which the technology is purchased.  Blechar used 5 similar categories to differentiate vendors which correspond to the same category if adopters:

• Early Impact Players
• Other Players
• Heavyweights
• Focused Players
• Consolidators

Bechar goes on to detail how adopters and vendors interact:

During the technology’s first two life cycle stages (Innovators and Early Adopters), the vendors in the market will be Early Impact Players and Other Players. As the market matures and technology enters the Early Majority stage of the life cycle, vendors that are Early Impact Players transform into Heavyweights or Focused Players. Some Other Players will disappear during the Early Majority stage, and a few may be able to become Focused Players or Heavyweights. As the Early Majority stage progresses, and to the end of the first half of the Late Majority stage, vendors may move between different classifications. Heavyweights may become Focused Players or disappear, and Focused Players may become Heavyweights or disappear. The risks of buying from Other Players that survive to the end of the first half of the Late Majority stage will remain high.

Another change happens as the technology moves into the second half of the Late Majority stage. By now, the market is approaching saturation and is beginning to consolidate. Some vendors that are Heavyweights and Focused Players will exit the market (particularly during the final Laggards stage of the technology life cycle); other vendors will be acquired or will merge to become Consolidators. As the technology life cycle draws to a close, the majority of vendors left in the market will be Consolidators. These will be the vendors that have the largest and most stable maintenance revenue and, in terms of technology risk, are the “best bets.” The technology risks associated with Other Players that survive into the second half of the Late Majority and Laggard stages are now at their highest.

The severity of the risks will change for the vendors as the technology life cycle of adoption progresses. Understanding how the risk levels change throughout the technology life-cycle can help potentially mitigate those risks by proactively addressing them.

Image Source: Blechar, 2006

References:

Blechar, Mike. (2006). Managing Technology Life Cycle Risks. (G00142109). Gartner.

The Enterprise Technology Architecture, Part 2

There are many times when we have certain expectations, and yet reality proves to be something different than expected.   Case in point, the image above shows us an expectation of a “virtual world” based on the 1999 movie, The Matrix, in contrast with an example of the recent personal virtual reality technology.  What we expected (or hoped for) is not what we got.   In the same way, this blog entry is not about virtual reality, but a discussion about system virtualization.

There is no spoon….

In general, virtualization refers to the technology that creates a logical (virtual) system instead of a physical system, specifically in the field of computer hardware.   This hardware can be servers, storage devices, or even network resources.  This practice started in a primitive form back in the 1960s on mainframe computers, but has gradually increased in scope and capabilities and is a mainstream technology used today.  In a simple breakdown, virtualization falls into the following categories:

• Platform/Hardware virtualization – A full virtual machine acts as a real computer with it’s own operating system.
• Desktop virtualization – A logical desktop which can run on any physical client while processing takes place on a separate host system.
• Application Virtualization – An application runs off a client machine, but in reality is being hosted on larger system which typically has greater processing power.

Interestingly enough, this has a direct correlation to the different service types provided in the cloud-computing environments, as I talked about a number of weeks ago in Let’s get Saassy.

• SaaS – Software as a Service: The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.
• PaaS – Platform as a Service: The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.
• IaaS – Infrastructure as a Service: The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).

This direct correlation is due to the fact that most cloud computing technology heavily relies on virtualization to function.  “Virtualization is a foundational element of cloud computing and helps deliver on the value of cloud computing. While cloud computing is the delivery of shared computing resources, software or data — as a service and on-demand through the Internet” (Angeles, 2014).

So how does virtualization tie back into Enterprise Technology architecture and Enterprise Architecture in general?

In response to a question regarding the impact of virtualization and cloud computing on Enterprise Architecture, John Zachman (2011), creator of the Zachman Framework, stated:

The whole idea of Enterprise Architecture is to enable the Enterprise to address orders of magnitude increases in complexity and orders of magnitude increases in the rate of change. Therefore, if you have Enterprise Architecture, and if you have made that Enterprise Architecture explicit, and if you have designed it correctly, you should be able to change the Enterprise and/or its formalisms (that is, its systems, manual or automated) with minimum time, minimum disruption and minimum cost.

Adrian Grigoriu, author of An Enterprise Architecture Development Framework, further expounded on the benefits virtualization brings to Enterprise Architecture (2008).

In this fast moving world, the business of an Enterprise, its logic, should not depend on IT technology, that is what it is or its implementation. Business activities should be performed regardless of technology and free from tomorrow’s new IT hype. Why be concerned whether it is mainframe, COBOL, JavaEE or .NET, Smalltalk, 4GL or AS400 RPG! At the same cost/performance level, IT should decide technology realizing that ongoing change is inevitable.

Business should be willing to adopt technology virtualization to be able to interact with IT technology at a service level, where the negotiation between business and IT is performed in a communication language structured in terms of capabilities, relative feature merits, and their cost. IT functional and non-functional capabilities will be delivered under SLAs at an agreed price.  IT virtualization adds an interface layer hiding the IT implementation complexity and technology, while bridging the divide between business and IT.

Even back in 2008 and 2011, Enterprise Architecture leaders realized the benefits that could be gained from virtualization.  Considering the growth of the technology since then, the benefits have exponentially multiplied.  EA ultimately relies on technology itself to be efficient, therefore, technology that allows for rapid changes will always be of primary importance.   In addition, virtualization brings reduced complexity, lowered costs, simplified IT management, improved security and flexible IT service delivery to the organization. These benefits not only help EA, but IT and the organization in general.

References:

Angeles, Susan. (2014). Virtualization vs. Could Computing: What’s the Difference?  Business News Daily.  Retrieved from http://www.businessnewsdaily.com/5791-virtualization-vs-cloud-computing.html

Zachman, John. (2011). Cloud Computing and Enterprise Architecture.  Zachman Internaltional. Retrieved from https://www.zachman.com/ea-articles-reference/55-cloud-computing-and-enterprise-architecture-by-john-a-zachman

Grigoriu, Adrian. (2008). The Virtualization of the Enterprise. BPTrends.  Retrieved from http://www.bptrends.com/the-virtualization-of-the-enterprise/

The Enterprise Technology Architecture, Part 1

Back in EA871, we were introduced to the concept of Enterprise Architecture and how it holistically links strategy, business and technology together.  I’ve frequently described the Masters program to my friends and associates as the combination of IT, an MBA program and Project Management.

EA has been defined by various technology organizations as:

• Gartner – Enterprise architecture is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. (http://www.gartner.com/it-glossary/enterprise-architecture-ea/)
• MIT Center for Information Systems Research – The organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model. (http://cisr.mit.edu/research/research-overview/classic-topics/enterprise-architecture/)
• Microsoft – An enterprise architecture is a conceptual tool that assists organizations with the understanding of their own structure and the way they work. It provides a map of the enterprise and is a route planner for business and technology change. (https://msdn.microsoft.com/en-us/library/ms978007.aspx)

For me, the easiest way to describe EA is the intersection of Business, Strategy and Technology:

We’ve talked about various aspects of the strategies of EA, but now let’s talk about the Technology.  What do we actually mean by technology architecture?  Michael Platt, senior engineer at Microsoft defined it within the framework of Enterprise Architecture:

A technology architecture is the architecture of the hardware and software infrastructure that supports the organization and implements the operational (or non functional) requirements, particularly the application and information architectures of the organization. It describes the structure and inter-relationships of the technologies used, and how those technologies support the operational requirements of the organization.

A good technology architecture can provide security, availability, and reliability, and can support a variety of other operational requirements, but if the application is not designed to take advantage of the characteristics of the technology architecture, it can still perform poorly or be difficult to deploy and operate. Similarly, a well-designed application structure that matches business process requirements precisely—and has been constructed from reusable software components using the latest technology—may map poorly to an actual technology configuration, with servers inappropriately configured to support the application components and network hardware settings unable to support information flow. This shows that there is a relationship between the application architecture and the technology architecture: a good technology architecture is built to support the specific applications vital to the organization; a good application architecture leverages the technology architecture to deliver consistent performance across operational requirements. (Platt, 2002)

In other words, it’s not the hardware or software themselves, but the underlying system framework. In the same way that EA provides standards and guidelines for technology in business, the Enterprise Technology Architecture (ETA) focuses on standards and guidelines for the specific technologies used within the enterprise.  Gartner defines ETA as “the enterprise technology architecture (ETA) viewpoint defines reusable standards, guidelines, individual parts and configurations that are technology-related (technical domains). ETA defines how these should be reused to provide infrastructure services via technical domains.”

So ETA is a formalized set of hardware & software, which meets various business objectives and goals, and includes the various standards and guidelines that govern the acquisition, preparation and use of said hardware and software.  These can be servers, middle-ware, products, services, procedures and even policies.  To be clear, ETA is not the same as System Architecture.  System Architecture deals with specific applications and data, along with the business processes which they support.  ETA is the technological framework which supports and enables those application and data services.

References:

Platt, M. (2002). Microsoft Architecture Overview. Retrieved from https://msdn.microsoft.com/en-us/library/ms978007.aspx