Convergence of Two Paradigms: Enterprise Architecture and Cloud Computing

We are addressing the issue of convergence of two paradigms—important for theory and practice of the use of information technologies in enterprises. Our goal is to shed light on complex relationships and dependencies between Enterprise Architecture and Cloud Computing—specifically, the synergy between these two paradigms, and ensuing consequences for any size enterprise. Our approach is to identify Enterprise Architecture views as perspectives on an enterprise, social groups involved in Enterprise Architecture and Cloud Computing, link them, and explain how both sides (i.e., Cloud Service users and Cloud Service Providers) may benefit from developing and maintaining Enterprise Architecture artefacts.

 

Essence of Enterprise Architecture

In the 1980s, John Zachman advanced the idea of describing enterprises by “…a set of architectural representations produced over the process of building a complex engineering product representing the different perspectives of the different participants (Zachman, n.d.). Even in his early papers, Zachman acknowledged that there was “…little consistency in concepts, or in specifications of ‘architecture’,” and that it was “…probably not reasonable to expect reconciliation or commonality of definition to emerge….” Furthermore, the author offered his framework “…for rationalizing the various architectural concepts and specifications in order to provide for clarity of professional communication, to allow for improving and integrating development methodologies and tools, and to establish credibility and confidence in the investment of systems resources” (Zachman, 1987).

Zachman’s Enterprise Architecture Framework is recursive; it can both serve as a metamodel to describe itself and model concepts that have nested parts and subparts that go to any depth. The Framework may be used to model any social or technical system (Sowa, 1992) that could consist of people only, people and computer systems, or computer systems only—that is, all types of enterprises—from a consortia of companies or governments, commercial organizations, business firms, and social ventures, to start-up businesses and projects undertaken (or to be undertaken).

The purpose of Enterprise Architecture is to enable managing social and engineering complexity by creating a perspective (or view) for each social group involved. Each view contains discourse relevant to a particular group of people, and represents their concerns. The view contains knowledge on the endeavour that the group made explicit, in order to communicate among its member, or with other groups, involved in the endeavour, and to carry on its function. Ultimately, integration of these views enables development of the enterprise system.

It is our position that the Enterprise Architecture views artefacts that constitute these views are ultimately products, and reflections of social activities, as these artefacts contain knowledge generated by social groups and individuals involved in enterprise architecture activities. We also assume that the organizational structure has impact on the Enterprise Architecture artefacts. However, since these topics are out of the scope of this paper, they may be addressed at a later date.

Enterprise Architecture Views

As mentioned above, enterprise architecture views do not have unique descriptions. Not only do the views and artefacts not have unique descriptions, but since the late 1980s, numerous enterprise architecture frameworks emerged. We mention only two—The Open Group Architecture Framework TOGAF (The Open Group, 2011), one of the most popular, and Zachman’s Enterprise Architecture Framework, that is, de facto, an ontology against which all other enterprise architectures are compared.

The Open Group Architecture Framework (TOGAF)

TOGAF introduced four views, or business domains:

1.Business Architecture (business strategy, governance, organization, and key business processes).

2.Data Architecture (structure of an organization's logical and physical data assets and data management resources).

3.Application Architecture (blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization).

4.Technology Architecture (logical software and hardware capabilities that are necessary to support the business, data, and application services, including, for example, IT infrastructure, middleware, networks, communications, processing, and standards).

TOGAF also recommends a phased process for Development of Enterprise Architecture that includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures.

However, TOGAF does not recommend any formal modeling for its representations (or views, or architectures).

Zachman’s Enterprise Architecture Framework

Zachman’s Enterprise Architecture Framework is best characterized as a two-dimensional scheme for classifying enterprise representations. It is described by the following view:

  • The Owner’s view (second row)—reflects the owner’ s (e.g., customer, user) conceptual point-of-view, owner’s expectations of the system, or how the owner wants to use the system, or whatever the owner thinks relative to the system, or endeavour
  • The Designer’s view (third row)—reflects the engineering concerns, and serves as the intermediary model between what is desirable (as represented by the second row) and what is possible physically and technically (as represented by the fourth row)
  • The Builder’s view (fourth row)—reflects the concerns of those who are supposed to build the system

There are three more views in the Zachman’s Enterprise Architecture Framework; those are:

1.The Scope or contextual view (first row)—by which the participants establish the universe of discourse, such as the system boundaries, the relevant representations, and participants.

2.Out-of-Context view (fifth row)—enumerates the parts of the physical system for production purposes.

3.Physical manifestation (sixth row)—physical manifestation, or functioning enterprise.

Social Aspects of Enterprise Architecture

Since the 1980s, the Enterprise Architecture concept has been evolving, and today, depending on the contextual factors (e.g., audience, knowledge, organizational culture), Enterprise Architecture may have different meanings, for example:

  • Social activities that plan and execute enterprise strategy, or enterprise IT only strategy, and produce Enterprise Architecture representations. Examples are social activities of planning enterprise resources, reviewing and gating IT architecture artefacts, defining organizational technical standards.
  • A group, or organizational unit (e.g., Enterprise Architecture group, or Enterprise Architecture team), that has a mandate to manage and produce enterprise architecture representations.
  • Representations where scope and content vary and encompass:

- a single blueprint of a corporation, with some, or all, of its facets (e.g., marketing, operations, governance)

- a set of organizational business process diagrams (e.g., customer facing business processes, financial business processes)

- a set of representations that model a technical system (e.g., logical data architecture, network architecture, logical application design, security architecture)

- a set of representations necessary to plan, design, construct and operate information-intensive systems (e.g., architecture reference models, descriptions of Enterprise IT Service Management practice)

- a set of enterprise standards (e.g., organizational technical standards)

Schools of Thought of Enterprise Architecture

Enterprise Architecture  and social activity around the evolution of this concept brought heterogonous frameworks and also heterogonous enterprise architecture schools of thought and communities of practice developed with complementary, or competing interests (Lapalme, 2011).

However, these schools of thought are not taking anything from the essential principles of enterprise architecture (i.e., set of models representing the different perspectives (or views) of the different participants in order to deal with complexity of endeavours). Quite contrary, they only emphasize the necessity of having generic enterprise architecture frameworks that enable dealing with complexity.  

For example, Lapalme (2011) identified three enterprise architecture schools of thought, and noticed that they differ in scope:

1.Enterprise-wide IT platform—models IT facet of an enterprise only.

2.Enterprise as a whole—includes all enterprise facets (e.g., governance structure, production, IT capabilities).

3.Enterprise and its environment—models enterprise and its environment, including relationships between the two.

Obviously, a generic Enterprise Architecture framework that supports recursivness (such as Zachman’s Enterprise Architecture Framework) may support all three scopes. It is up to the participants to set up the scope; that is, the system boundaries.

Who are the Participants

At this point, we need to identify participants in enterprise building. The concept of Enterprise Architecture is introduced as a tool for managing complexity of Information Systems, and, as shown above, the division on development of core activity (e.g., business) and development of technical system is present in enterprise architecture frameworks (e.g., TOGAF, Zachman.) The division between core activity of an enterprise and IT (e.g., IT department) is the most common way of organizing these facets in an enterprise. Most importantly, the perspectives of these two major groups are different and their discourse may be entirely different. Therefore, we distinguish two groups of views – Enterprise perspective (all facets with or without IT, including enterprise environment) and IT perspectives.

Enterprise Perspective

Examples of Core Enterprise Activity are Commercial Products, Business Services, Government Services, and Social Projects. The involved social groups are:

Governance and Management—include people who have power and resources to strategize, plan, and initiate enterprise activities. Whatever the size of the enterprise, senior management is always present, whether directly, or via other management groups, such as the Business Management and Project Management Office (PMO).

Core Enterprise Activity—includes people who execute enterprise core activities. Their motivation in regards to Enterprise Architecture is related to their day-to-day jobs, and includes increased, and demonstration of increased, productivity, job security, advancing on the organizational latter.

Third Party Vendors and Service Providers—include enterprises with third party staff and services, for example third party consultants, third party subject matter experts, third party software or hardware vendors.

Legal and Regulatory Facets and their Representatives—include legal advice necessary for specific events (e.g., privacy impact), or controlling functions, such as auditors or regulators (e.g., service level agreements).

Supporting Facets- includes Finance, Human Relationships

Enterprise Service or Product Consumers—Depending on the scope and the core activities of the enterprise, these include, for example, various users, subject matter expert groups, and the public. They rarely have any direct impact on service or product design, but they are users of enterprise services and products; thus, they are highly motivated in regards to those services and products, but they do not participate in Enterprise Architecture activities. They all benefit from the Core Services; for example, the public users may benefit from various ‘Government Online’ services, or scientist may benefit from technology used to support their research

Information Technology Perspective

Information Technology (IT) Governance and Management—include people who strategize, plan, and initiate enterprise IT activities. IT is seen as a facet of the enterprise. In some organizations, IT managers may not be included in the enterprise senior management teams. Even the Project Management Office (PMO) may be considered core activity, rather than IT.

IT Functional Architects—Depending on the scope of the enterprise (or project), there may be a number of functional architects (e.g., business, information, application, systems, technical, solution, enterprise, security and privacy architects).

Other IT Functional Groups—There are other Software Development Life Cycle (SDLC) functional groups, such as design, development (sometimes various programming languages), testing, operations (including operational security), and maintenance. Depending on the scope, various profiles and levels of hardware specialists may be involved.

Communication and Knowledge Transfer

In a functional enterprise, communication and knowledge transfer among all these participants (i.e., enterprise-wide) must be enabled.

Because the above participants often have different geographical, political, language, and cultural backgrounds, the social dynamics of IT endeavors are made even more complex. Stakeholders also come from a variety of different educational backgrounds and functional groups, from MBAs, economists, engineers and various business subject matter experts, to accountants, lawyers, and those without formal education for their jobs.

These differences make communication among participants particularly uncertain. It is easy to see how in these diverse and complex social environments, communications, and relationships among the stakeholders may be distorted, or broken. In such environments, power, money games, and politics can easily take precedence over creativity, innovation, and constructive activities essential for meeting the endeavor’s objectives. The IT endeavor can easily be high jacked to serve interests other than meeting (or exceeding) the intended objectives.

The simple reality is, however, that IT demanding endeavours may experience difficulties (or completely fail) because of uncertainty in any of the participants’ functional areas. It is in the nature of IT that uncertainty originating in one participant’s functional area will usually impact another.

Relationships between IT and other Facets of the Enterprise

When surveying the literature on this subject, it is clear that many authors recognize the importance of IT in enterprise (Bloch, Brown, & Sikes, 2012). However, also recognized is a long-standing tension, almost an animosity, between the IT department and the other departments in any enterprise (Saha, 2012). Inadequate communication and knowledge transfer among IT participants and the rest of the enterprise can generate risk. Some such examples of these risks include a lack of clearly articulated and well-communicated product innovation and technology strategy (Cooper, 2010) and “perfect” design created for unsustainable strategies (Lapalme, 2011). This complex relationship between ICT and the rest of the enterprise needs to be dealt with somehow in order for enterprise to function well.

The days when the IT mission was only to reduce costs or improve operations are long gone. IT evolved to create entirely new kinds of businesses and business models that are based on the Internet and the World Wide Web. Many IT corporations, such as Google, Facebook, and Apple, have achieved unprecedented business success (Melanson, 2012), (Reguly, 2012). And there are other non-IT companies that managed to embrace and invent new technologies and adapt their business models accordingly with varying degrees of success. For example, the adaptation of Fuji was a success; whereas the adaptation of Kodak was much less so (The Economist, 2012).

Most importantly, in today’s economy with budgets shrinking around the world (for example, Ontario Public Service [OPS, 2012], UK Police [Gohring, 2012], USA Military Aerospace [Keller, 2012], and technology in general [Strohm, 2012]), it seems that everyone has to produce more for less, or face gloomy predictions.

Cloud Computing

Cloud Computing has evolved to enable the use of computing resources from anywhere and anytime (Ramachandran, 2011). Cloud Computing is promising to deliver technological services on demand, in a similar manner that an enterprise may purchase utilities. As a utility it is also promising virtualisation and distributed computing. In addition, Cloud Computing assures service-oriented architecture, low cost of ownership, less information technology overhead for the consumers, and far more flexibility than is present today (Ramachandran, 2011). Cloud Computing is gaining momentum both in the marketplace (Herbert & Erickson, 2011), (Brynjolfsson et al., 2010), and in new application domains (e.g., biomedical research (Rosenthal et al., 2012)).

There are three main types of Cloud Computing services to consider:

1.Infrastructure as a Service (IaaS)—Cloud Service Provider (SP) manages IT infrastructure.

2.Platform as a Service (PaaS)—Cloud SP manages IT platforms on which applications run.

3.Software as a Service (SaaS)—Cloud SP enables application services for its users.

The cloud architecture, its layers, and its service offerings need to be designed for scalability and re-configurability as they have to support service level agreements with Cloud Service consumers. Thus, as proposed by Muthu Ramachandran (2011), it is essential to design Cloud applications and services based on proven architecture paradigms, methods, and techniques including sound security controls.

Cloud Computing is so appealing because it claims a solution to the poor relationship between IT and the rest of the enterprise. It does so by promising to treat IT as just another utility, removing any complexity in IT’s relationship with the enterprise as a whole. Despite Cloud Computing’s appeal of simplicity, a more recent McKinsey Global Survey of 1,469 C-level executives across various industries reported that only 34% of them are using Cloud Computing (McKinsey, 2012). Although Cloud Computing offers a possible solution to the problem of poor relationships between IT and the rest of the enterprise, it does not fully take into account the importance of IT in any functioning business. Perhaps Cloud Computing’s reduction of IT to the status of utility is not viable in today’s enterprise environment. After all, technology is considered omnipresent (Leveson, 2011), and it is difficult to pinpoint an endeavour that is not IT demanding.

On Convergence of Enterprise Architecture and Cloud Computing Paradigms

It could be expected that with the availability of Cloud Computing services, complexities related to organizational management of IT departments are removed and associated enterprise architecture views are eliminated. However, this is not necessarily the case. For example, if an organization seeks to align its business and IT services and purchases those services from a Cloud Service Provider, the organization must still design, or at least be aware of, its business processes and related requirements. Thus, the organization still needs its business architecture, which contains models of organizational business processes and related requirements. These requirements still have to be matched with the offerings of the Cloud services, and their compliance with these services has to be assessed.

Cloud paradigm does not completely eliminate a need for having an Enterprise Architecture—only the content of the Enterprise Architecture may change. For example, business architecture (which is considered a layer of an Enterprise Architecture) may still be necessary but other layers (e.g., system and technical) may be significantly reduced. We also plan to consider that there are other challenges or consequences related to Cloud Computing, such as security, risk exposure, integration, and Cloud Service Provider management, which any enterprise has to ultimately balance.

On the other hand, the Cloud Service Provider also needs its Enterprise Architecture, starting with its own business architecture. For example, as the Cloud Service Provider user base grows, the service requirements will typically become more complex, perhaps even conflicting. In essence, with Cloud Service Provider operations becoming more complex, the need for enterprise architectures to consolidate and optimize Service Provider operations increases. In order to maximize and re-use, Cloud Service Providers need to optimize granularity of their software resources which may have negative consequences on the flexibility and extensibility of their services (Ramachandran, 2011). It is essential to identify principles for the design of their resources which again calls for Enterprise Architecture.

Another example of a need for the convergence of Enterprise Architecture and Cloud Computing is that the public (consumer) view may become increasingly important because of the growing number of users who access Cloud services via a variety of mobile devices. As Cloud Computing takes hold in an enterprise, a need for having sound standards and, perhaps, creation of various regulatory bodies, rises. Enterprise architecture may offer methods for structuring these standards and views. We propose that there exists a need to rethink Enterprise Architecture methods and concepts in order to make the two paradigms not only converge, but work in synergy.

Conclusion

The examples above illustrate the convergence of the two paradigms: Enterprise Architecture and Cloud Computing. We posit that the need for enterprise architecture cannot be eliminated by Cloud Computing. Quite the contrary, it is our position that the importance of having sound Enterprise Architecture will only grow with the utilization of Cloud Computing. We also posit that Enterprise Architecture may have to get new use cases and new views.

Despite its claims, Cloud Computing does not remove complexity, nor the need for Enterprise Architecture. Now that there might be more Cloud Service Providers, this adds a complexity in management. Zachman suggests that he does not expect that companies will give their core or critical applications to the Cloud Service Providers (Zachman, n.d., 2). However, that is exactly what would be most compelling to see – how capable companies who can articulate their business needs will use the Cloud. And, in order to benefit from Cloud Computing, these companies must have a clearly articulated business and systems architecture which is why Enterprise Architecture is still needed. Furthermore, use of formal models and knowledge representation methods could encourage measuring and comparison of the organizational knowledge that was made explicit in Enterprise Architecture artefacts

Similarly, Cloud Service Providers that can organize their operations to be able to serve more clients and adapt to their clients’ needs will have an advantage in their market niche. The most effective way for Cloud Service Providers to develop this ability to adapt and respond to potential client needs is to structure their enterprise through Enterprise Architecture.

Seeing as complexity will not go away anytime in the near future, Enterprise Architecture will not disappear either. In addition, the better organized that Cloud Service Providers and companies are, the more competitive they can be.

 

References:

Birman, K., Chockler, G., van Renesse, R. (2009). Toward a Cloud Computing Research Agenda. [LADIS 2008 - annual workshop focusing on the state of the art in distributed systems], New York, NY: ACM SIGACT News, 40 (2), pp 68-80. Retrieved from http://dl.acm.org

Bloch, M., Brown, B., Sikes, J. (2012). Elevating Technology on the boardroom agenda. McKinsey & Company. McKinsey on Business Technology 27. Retrieved from http://www.mckinsey.com/client_service/business_technology  

Brynjolfsson E., Hofmann P., Jordan J. (2010). Cloud Computing and Electricity: Beyond the Utility Model. New York, NY: Communications of the ACM 53(5), pp 32-34.

Cooper, G. R., Edget, J. S. (2010). Developing a Product Innovation and Technology Strategy for Your Business. New York, NY: Research Technology Management 53 (3), pp 33-40. Available online at http://www.stage-gate.net/downloads/working_papers/wp_39.pdf

Gohring, N. (2012, March 14). Shrinking Budgets Spur Creativity in Public Safety IT. PC World. Retrieved from http://www.pcworld.com/businesscenter/article/251846/shrinking_budgets_spur_creativity_in_public_safety_it.html

Herbert, L., Erickson, J. (2011). The ROI of Cloud Apps. Cambridge, MA: Forrester Research.

ISO/IEC/IEEE 42010:2011. Systems and Software Engineering – Architecture Description. Retrieved from http://www.iso-architecture.org

Jaeger, P. T., Lin, J., Grimes, J.M. (2008). Cloud Computing and Information Policy: Computing in a Policy Cloud. Amherst, MA: Journal of Information Technology and Politics, 5(3). Available online at http://www.haworthpress.com

Keller, J. (2012, March 1). Military Aerospace. Retrieved from http://www.militaryaerospace.com/articles/print/volume-23/issue-3/news/trends/the-incredible-shrinking-budget-for-us-military-technology-research.html

Lapalme, J. (2011, December 14). Three Schools of Enterprise Architecture. Washington, D: IT Professional. doi.ieeecomputersociety.org

Leveson, G. N. (2011). Engineering a Safer World. Massachusetts Institute of Technology.

Mahmood, Z., Hill, R. (Eds.). (2011). Cloud Computing for Enterprise Architectures. Heidelberg, Germany: Computer Communications and Networks, Springer-Verlag.

Melanson, T. (2012, February 2). Why Facebook may not be the next Google. Canadian Business Network. Retrieved from http://www.canadianbusiness.com/blog/tech/69092--why-facebook-may-not-be-the-next-google

McKinsey (2012). Minding your digital business: McKinsey Global Survey results. McKinsey & Company. McKinsey on Business Technology 27. Retrieved from http://www.mckinsey.com/client_service/business_technology

MIT CISR (n.d). Enterprise Architecture Introduction. Massachusetts Institute of Technology (MIT) – Center for Information Systems Research website. Retrieved from http://cisr.mit.edu/research/research-overview/classic-topics/enterprise-architecture/

OPS. (2012) Commission on the Reform of Ontario’s Public Services – Executive Sumary. http://www.fin.gov.on.ca/en/reformcommission/chapters/executive-summary.pdf

Ramachandran, M. (2011) Component-Based Development for Cloud Computing Architectures. Cloud Computing for Enterprise Architects. Eds. Mahmood, Z., Hill, R. Heidelberg, Germany: Computer Communications and Networks, Springer-Verlag, pp. 91-114.

Reguly, E. (2012, January 27). Why Apple’s success is out of this world? The Globe and Mail. Retrieved from http://www.theglobeandmail.com/report-on-business/rob-commentary/why-apples-success-is-out-of-this-world/article4202383/

Rosenthal, A., Mork, P., Hao, L.M., Stanford, J., Koester, D., Reynolds, P. (2012). Cloud computing: A new business paradigm for biomedical information sharing. Journal of Biomedical Informatics 43.

Saha, P. (2012, February 12). Six Reasons why EA should not be assigned to IT department. Business Architecture Community group discussion. LinkedIn.

Sowa, J.F., Zachman, J.A. (1992). Extending and formalizing the framework for information systems architecture. IBM Systems Journal, vol 31, No3, 1992

 

Strohm, C. (2012, February 16). Obama Budget Calls for Cuts in Spending for U.S. Technology. Bloomberg Businessweek. Retrieved from http://www.businessweek.com/news/2012-02-16/obama-budget-calls-for-cuts-in-spending-for-u-s-technology.html

The Economist. (2012, January 14). The last Kodak moment? Retrieved from http://www.economist.com/node/21542796?fsrc=scn/fb/wl/bx/14jan12

The Open Group (2011). The Open Group Architecture Framework, version 9.1. Berkshire, UK. Retrieved from http://pubs.opengroup.org/architecture/togaf9-doc/arch/

Zachman, J. (2011). The Zachman Framework for Enterprise Architecture: A Primer for Enterprise Engineering and Manufacturing. La Canada, CA: Zachman International. Retrieved from http://test.zachmaninternational.com

Zachman, J. (1987)      Zachman John. “A Framework for Information Systems Architecture”, Armonk, NY: IBM Systems Journal, 1987, 26 (3).

Zachman, J., (n.d.)        Yes, “Enterprise Architecture Is Relative” But It Is Not Arbitrary. La Canada, CA: Zachman International. Retrieved from http://www.zachman.com/ea-articles-reference/57-eanotarbitrary

Zachman, J. (n.d.,2)     Cloud Computing and Enterprise Architecture. La Canada, CA: Zachman International. Retrieved from http://www.zachman.com/ea-articles-reference/55-cloud-computing-and-enterprise-architecture-by-john-a-zachman

 

 

Rubina Polovina, PhD is a principal IT consultant who has been providing leadership on national and international multi-party initiatives in the public and private sectors. During more than 20 years in the IT industry, she contributed to projects in Europe, North America and in the Middle East.

Currently, Rubina lives in Toronto, Ontario. She has been working on projects at major Canadian financial institutions and the Government of Ontario. Her research interests include enterprise architecture, knowledge management, IT management, IT project management, IT risk management, privacy protection, social networks and eHealth. Rubina’s scientific work has been both tested across various vertical industries and presented on peer-review international conferences.

Rubina graduated in electrical engineering in 1987 from the University of Sarajevo, Bosnia and Herzegovina, and she received her PhD in computer science and engineering in 2000 from the Czech Technical University in Prague, Czech Republic. Contact: This email address is being protected from spambots. You need JavaScript enabled to view it.">This email address is being protected from spambots. You need JavaScript enabled to view it.

Comments (0)
Only registered users can write comments!