Standing Up an Enterprise Architecture Center of Excellence and a Certification Program at Your University

EXECUTIVE SUMMARY

This article proposes the establishment of a Center for Operations, Research and Education (CORE) at your university. CORE would be a team of people that proactively and holistically help achieve university’s business outcomes. Its mission would be to provide comprehensive educational programs in Enterprise Architecture, conduct research and use this research to help transform the university.

For this article, the strategic direction and cultural factors in relationship to operations, research and education in Enterprise Architecture are considered. We assume status quo in regards to your university’s culture for this assessment, specifically the perception of Information Technology. The following table shows what we considered:

  Operations Research Education
Current State (Observations)
  • No one is responsible for Enterprise Architecture
  • No research is being conducted in this field
  • No comprehensive program in Enterprise Architecture
Future State (Recommendations)
  • CORE would be independent of your university’s President
  • Rotating leadership where every school, department and division has the opportunity to lead CORE
  • Conduct research by partnering with other elite institutions
  • Begin by providing a graduate certification program
  • Aim for providing Bachelor’s, Master’s and executive programs in the future

This assessment reveals that currently where Enterprise Architecture is placed in the organization, it will not be able to provide the organizational transformational value that is aspires to provide. Additionally, your university should start providing comprehensive programs in this field otherwise they would be left behind other educational institutions that are already moving in this direction.

1. ANALYSIS

This section provides an analysis of standing up CORE from an operational, research and educational prospective.

Assumptions

  1. Your university’s executive management would support this effort
  2. All university communities would help transform it to achieve operational excellence
  3. Perception of IT would not change instantly

1.1 What is Center of Excellence?

According to Tarek M. Khalil et al. (2001), within an organization, a Center of Excellence may refer to a group of people, a department or a shared facility. It may also be known as a Competency Center or a Capability Center. The term may also refer to a network of institutions collaborating with each other to pursue excellence in a particular area.

1.2 What is Enterprise Architecture?

Due to the evolving nature of this field, there are many academic and practitioner definitions of what is Enterprise Architecture. For our purposes we will use the one definition from the glossary on Gartner’s website that states Enterprise Architecture as a discipline for proactively and holistically leading enterprise responses to disrupt forces by identifying and analyzing the execution of change toward desired business vision and outcomes. Enterprise Architecture delivers value by presenting business and Information Technology (IT) leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. Enterprise Architecture is used to steer decision-making toward the evolution of the future state architecture.

In a nutshell, “Enterprise Architecture bridges the Business and Information Technology via enterprise integration/standardization resulting in people becoming more efficient and effective in achieving their objectives.” Kevin Smith (2010)

It should be noted that Enterprise Architecture is not an Information Technology endeavor but in fact it sits in between Business and IT and works across organizational silos.

1.3 What is CORE?

If we combine the two definitions above then a definition for center of excellence in enterprise architecture emerges which is a team of people that proactively and holistically helps achieve business outcomes. For your university and breadth of this center’s agenda, it would be called Center for Operations, Research and Education (CORE).

1.4 What is the Operational Perspectives?

1.4.1 Why should Your University Pay Attention to Enterprise Architecture?

One of the biggest proponents and users of Enterprise Architecture is the most powerful office in the world – The White House. The United States Federal Government has been using Enterprise Architecture for more than a decade and continues to see it as a way to look across organizational silos.

What this means for your university is that, huge organizations are trying to improve their operations and they are turning towards Enterprise Architecture to help them do that. Your university can tap into this, apply Enterprise Architecture effectively and perhaps get involved in Enterprise Architecture discussions for organizational improvements. This involvement could also translate into future research grants and job opportunities for students.

1.4.2 Why putting Enterprise Architecture under Information Technology is Not a Good Idea?

All organizations are a composition of many cultures and subcultures. Some of these cultures develop over time and then become part of the routine mentality of an organization. Your university is not immune from this. In order to understand the perception of Information Technology at your university, look at how the university’s strategic plans were developed. Was Information Technology involved/invited to help in the development of your university’s strategic plan?

If not, then this is a cultural issue and often the cause of misalignments within organizations. Whenever Information Technology is not involved in strategic planning, it gives the perception that Information Technology is not important, it is just a commodity and it is just back office activities. This lack of involvement is the reason that according to the 2013 Chief Information Officer ‘State of the CIO’ survey, “63% [of the respondents] say the majority of their time and focus is spent on aligning Information Technology initiatives with business goals.” This shows there are gaps in aligning Business and Information Technology. This alignment can be achieved through Enterprise Architecture. According to a Gartner study (G00146809), Business-Information Technology alignment is the primary driver for Enterprise Architecture as shown below:

Primary Driver for Enterprise Architecture

Taking into consideration the current culture at your university, placing Enterprise Architecture under Information Technology would not make sense. If Enterprise Architecture continues to be placed under Information Technology then at your university Enterprise Architecture would be perceived as an “Information Technology thing”. This perception would defeat the overarching purpose of Enterprise Architecture. Enterprise Architecture needs to have a holistic understanding of your university going beyond Information Technology. A Gartner study (G00245986) supports this thought of Enterprise Architecture going beyond Information Technology as shown below:

Enterprise Architecture beyond IT

From the above figure, we can learn that while technology is a consideration in Enterprise Architecture but it is certainly not the only aspect that needs to be considered. A well-run CORE at your university would consistently produce qualitative and quantitative for both Business and IT. Some of examples of these are:

  • Qualitative Benefits
    • Improved Communications Across Organizational Silos
    • Increased Productivity
    • Efficient Portfolio Management
    • Effective Business Intelligence
  • Quantitative Benefits
    • Reduced Costs
    • Revenue Generation

1.4.3 What are the Maturity Levels for Enterprise Architecture?

According to a Gartner study (G00252206), it outlines the five levels of Enterprise Architecture maturity shown below:

Enterprise Architecture Levels of Maturity.png

What this means is that a lot of work needs to be done in this area and your entire university has to be involved in it so that it can be used effectively across organizational boundaries.

1.4.4 How will CORE Measure its Success?

From an operational prospective, a Gartner study (G00247593) indicates the following ways to align Enterprise Architecture to strategic business initiatives:

Align Enterprise Architecture to Strategic Business Objectives

At your university, success of Enterprise Architecture would depend upon how it can help your university transform itself to achieve its strategic visions.

1.5 What are the Educational and Research Perspectives?

1.5.1 Is Enterprise Architecture Taught at Your University?

Are Enterprise Architecture courses taught at your university in various schools (e.g., business school, engineering school, professional studies school etc.)? If yes, do you know if these schools at your university are talking to each other about Enterprise Architecture? If not, then there is no comprehensive Enterprise Architecture program at your university. From this observation, we can decipher that although Enterprise Architecture might be part of certain programs but overall it is fragmented at your university.

1.5.2 Why Should Your University Teach or Do Research in Enterprise Architecture?

In order to be an elite institution, your university needs to look at what other elite institutions are doing, assess what programs they offer and what kinds of research they are pursuing. Your university should then look at how these programs can be stood up.

For the purpose of this article, we will only focus on the institutions that teach, conduct research and/or have comprehensive programs in Enterprise Architecture. These include:

  Institutions Name Country
1 Harvard University USA
2 Massachusetts Institute of Technology USA
3 Dartmouth College USA
4 Carnegie Mellon USA
5 Pennsylvania State University USA

2. Recommendations

Due to the importance of Enterprise Architecture as a catalyst in organizational transformation, in the current culture at your university, CORE should not be under IT. CORE’s mission is to help your university continuously evolve, conduct/use research and provide comprehensive educational programs. It should be an interdisciplinary entity whose members include all schools, divisions and departments of your university. Thus, it should be placed where it has the most influence as shown below:

CORE at your university.png

CORE should start as a chartered center initially led by School of Business and in collaboration with Engineering School, Professional Studies School and IT. Within the first year this would develop relationships across all the university.

CORE’s leadership should be on a rotating basis where each school, department and division of your university has the opportunity to lead CORE for at least 1 year. This will create an atmosphere of collaboration and help break down organizational silos. This governance structure would also encourage participants to be actively involved in CORE’s advancement and they can use it to also enhance their own schools, divisions and departments.

In regards to education and research, CORE should develop a graduate certificate program with the goal of creating Bachelor’s, Master’s and executive programs in the future.

References:

  1. Tarek M. Khalil; L.A. Lefebvre; Robert McSpadden Mason (2001). Management of Technology: The Key to Prosperity in the Third millennium: Selected Papers from Ninth International Conference on Management of Technology, Emerald Group Publishing, pp.164
  2. IT Glossary, Enterprise Architecture, http://www.gartner.com/it-glossary/enterprise-architecture-ea/
  3. Kevin Smith (2010), Pragmatic EA: The 160 Character Challenge, Version 1.3, pp.12
  4. White House (2012), http://www.whitehouse.gov/sites/default/files/omb/assets/egov_docs/common_approach_to_federal_ea.pdf
  5. CIO Magazine (2013), ‘State of the CIO’ Survey, pp.4
  6. Robert A. Handler (2007). Key Issues for Enterprise Architecture. Retrieved from Gartner database.
  7. Julie Short (2013). Agenda Overview for Enterprise Architecture. Retrieved from Gartner database.
  8. Chris Wilson (2013). ITScore Overview for Enterprise Architecture. Retrieved from Gartner database.
  9. Betsy Burton (2013). EA Business Value Metrics You Must Have Today . Retrieved from Gartner database.
  10. Harvard University, IT for Management, http://hbsp.harvard.edu/list/it-for-management-toc
  11. Massachusetts Institute of Technology, Center for Information Systems Research, http://cisr.mit.edu/research/research-overview/classic-topics/enterprise-architecture/
  12. Dartmouth College, Auburn Cyber Research Center, http://www.ists.dartmouth.edu/events/abstract-hamilton.html
  13. Carnegie Mellon, Institute for Software Research, http://execed.isri.cmu.edu/elearning/enterprise-architecture/index.html
  14. Pennsylvania State University, Center for Enterprise Architecture, http://ea.ist.psu.edu

What is the relationship between Cloud Computing and SOA?

According to the publication from Mitre, Cloud Computing and Service Orientated Architecture (SOA), cloud computing has many services that can be viewed as a stack of service categories. These service categories include Infrastructure-as-a-Service (IaaS, Platform-as-a-Service (PaaS), Storage-as-a-Service, Components-as-a-Service, Software-as-a-Service (SaaS) and Cloud Clients. The following figure shows the service categories stack as depicted in the Mitre publication:

Mitre's Cloud Stack

Mitre’s Cloud Stack

SOA is a framework that allows business processes to be highlighted to deliver interoperability and rapid delivery of functionality. It helps system-to-system integration by creating loosely coupled services that can be reused for multiple purposes. The concept of SOA is similar to Object-Orientated Programming where objects are generalized so that they can be reused for multiple purposes.

Now that we have an understanding of the various types of Cloud Computing services and SOA, lets explore how Cloud Computing and SOA are similar and different.

Similarities between Cloud Computing and SOA:

  • Reuse – Conceptually speaking, the idea of reuse is inherent both in Cloud Computing and SOA.
  • As needed basis – In Cloud Computing, the services are provided to the users on demand and as needed. SOA is similar to this since the system-to-system services are on demand and as needed as well.
  • Network Dependency – Cloud Computing and SOA both require an available and reliable network. If a network does not exist then the cloud services provided over the Internet would not be possible. Similarly, if a network does not exist then the communications between systems would not be possible. Thus, both Cloud Computing and SOA are dependent on a network.
  • Cloud Contracts – In Cloud Computing, contracts entail the mutual agreement between an organization and cloud service providers. In cloud contracts, there is a cloud service provider and a cloud service consumer (the organization). In the case of SOA, contracts are important and can be either external (e.g., Yahoo! Pipes) and/or internal (e.g., organizational system integration). In SOA contracts, there are service producer(s) and service consumer(s) that are conceptually similar with cloud contracts.

Differences between Cloud Computing and SOA:

Despite the similarities between Cloud Computing and SOA, they are not the same. Following are some of the differences between them:

  • Outcome vs. Technology – In Cloud Computing, we are paying for the outcome but in SOA we are paying for technology.
  • External vs. External and/or Internal Point-of-View – In Cloud Computing, the services that organizations get are from external organization but in SOA these services can be either from external organizations (e.g., Yahoo! Pipes) and/or internally (e.g., system-to-system integration between two or more systems).
  • IaaS, PaaS, SaaS vs. Software Components – In Cloud Computing, the services provided can go up and down the stack but in SOA the services are software components.

References:

  1. Raines, Geoffrey. “Cloud Computing and SOA.” The MITRE Corporation. The MITRE Corporation, Oct. 2009. Web. http://www.mitre.org/publications/technical-papers/cloud-computing-and-soa
  2. Gedda, Rodney. “Don’t Confuse SOA with Cloud.” CIO. CIO Magazine, 28 July 2010. Web. http://www.cio.com/article/2414614/cloud-computing/don-t-confuse-soa-with-cloud.html

How to select an Enterprise Architecture Framework?

EXECUTIVE SUMMARY:

This article provides in detail the elements of an Enterprise Architecture (EA) framework that would be selected and deployed at a fictional United States (US) Federal Government contractor called FedCon. FedCon is divided into 3 Business Units (BUs) that are focused on providing Management Consulting, Information Technology (IT) Consulting and Systems Integration (SI) Services in Healthcare, Environment and Finance.

This article analyzes FedCon in terms of Strategies, Politics, Innovation, Culture and Execution (SPICE) as shown below:

  Stakeholders Domains
Strategies CEO, COO and CIO Business-IT alignment
Politics BU SVPs, PMO and program/project managers Technology products and services
Innovation Employees directly interfacing with customers Technology products and services
Culture PMO, HR and Accounting/Finance Leverage the massive intellectual property
Execution All employees Organizational performance

Based on the above, it is determined that The Open Group Architecture Framework (TOGAF) would be the appropriate EA framework at FedCon since (1) it is supported by multiple vendor tools (2) it is constantly being improved upon and (3) it has an Architecture Development Methodology (ADM) which can be used as a guide.

ABOUT FEDCON:

FedCon is a fictional 30 year old large publically traded US Federal Government contractor that provides Management Consulting, IT Consulting and SI services to civilian agencies. It has over 5,000 employees nationwide and it is structured into three Business Units (BUs). Each BU has domain expertise in Healthcare, Finance or Environmental information systems. This structure allows the BUs to work directly with the civilian agencies based on their missions. Each BU has its own account/business development (BD) team that reports to the BU Senior Vice President (SVP). The Program/Project Managers report to the BU SVP and provide status updates on programs/projects to the corporate Program Management Office (PMO). The PMO conducts weekly meetings to provide guidance on corporate standards, compliance and general project templates.

Organizational Structure

Organizational Structure

PROBLEM STATEMENT:

Over the past couple of years FedCon has lost 20% of its business. The CEO has been under pressure by the shareholders to turn the company around. Thus, the CEO hired a management consulting firm to determine what were the pain points within FedCon that were preventing it from staying competitive in the marketplace. The management consulting firm’s report revealed that due to inefficient business processes and outdated technologies FedCon’s BUs were not able to collaborate efficiently to manage business and technology changes. Based on these findings in the report, the CEO mandated the Chief Operation Officer (COO) and Chief Information Officer (CIO) to work together to find areas that they can improve in the next 12 months.

ANALYSIS:

In order to address the CEO’s concerns, the COO and CIO came to the conclusion that in order to help FedCon create a disciplined approach to managing strategic intent and its execution they had to look into the field of Enterprise Architecture. Thus, the COO and CIO decided to standup an Enterprise Architecture Program Management Office (EAPMO) that would report directly to the CIO. Initially, the EAPMO is tasked with determining the high level criterions to select a framework. This task includes providing elements of the framework to be used and how the framework would be applied within FedCon..

In this article, we assess the feasibility of an EA framework that can be used in FedCon by making observations about Strategies, Politics, Innovation, Culture and Execution (SPICE) factors. These factors would focus on understanding the people, processes and technologies at FedCon to create an effective EAPMO.

 

SPICE Factors

SPICE Factors

Strategies at FedCon:

At FedCon, there are multiple levels of strategies that are developed. These strategies include: (1) the corporate strategy determined by the CEO, (2) the operational strategy determined by the CFO, COO and CIO, (3) the BU strategy determined by the BU SVPs and (4) the PMO strategy determined by the PMO office. This is shown below.

Multiple Corporate Strategies

Multiple Corporate Strategies

As we can see from the above figure, each strategy layer addresses different domains for the various stakeholders. Even though these strategies are developed to increase the bottom line and decrease costs, they are created in isolation. Additionally, since each BU is somewhat autonomous it can create technology products and solutions for the civilian agencies that overlap with corporate products and solutions. This is a problem since not leveraging the corporate assets where applicable for client delivery can result in program/project delays and duplicative systems.

The primary strategic concerns in choosing an EA framework are:

  1. Stakeholders – CEO, COO and CIO are the strategic stakeholders and the executive sponsors of the EAPMO.
  2. Domain – Strategically, FedCon is interested in alignment of business and IT operations and efficient processes.

FedCon has never stood up an EA practice and thus it would be wise to select an EA framework that could guide them in what to do and that it has been proven in the industry to be useful for organizations that are just starting out their EA journey. These high level strategic criterions are fulfilled by The Open Group Architecture Framework (TOGAF) that provides an Architecture Development Methodology (ADM) as a step-by-step guide and includes how to do stakeholder management.

Politics at FedCon:

Generally, when we talk about the politics in an organization we are referring to the negative connotations attached with it. But for our purposes we will define politics to mean the formal power or informal power of an individual or group within an organization. The power exhibited by these individual and groups can turn into obstacle or support to bring about organization-wide changes. In this sense, here we refer to formal power as the reporting structures while informal power refers to the influence yielded based upon size of the BU, revenue generated by BU, headcount of BU and close relationships of BU leadership with the executives.

At FedCon, even though the BU SVPs have the same title, they don’t have the same power. Taking this into account and the emphasis by the US Federal Government Executive Branch to focus on healthcare issues, the largest and most profitable among the FedCon’s BUs is the healthcare BU. Due to this reason the healthcare BU SVP has more informal power among its peers. This means that if the healthcare BU can be convinced of the merits of the EA practice then we can come one step closer to a FedCon-wide EA practice.

The primary political concerns in choosing an EA framework are:

  1. Stakeholders – BU SVPs, PMO and program/project managers are the political stakeholders. The BU SVPs have formal power to bring change within their respective BUs. The PMO is a well-established office and it has visibility into the various kinds of projects and has informal power by pushing down changes to the project level within different BUs. Lastly, the program/project managers within BUs are stakeholders as well since they have to indoctrinate their teams on how EA can be used as leverage when developing client technology products and services.
  2. Domain – Politically, agreement, collaboration and coordination across BUs and the corporate team seems to be the area of focus to rapidly bring technology products and services.

Due to the “friendly” competition among BUs to become bigger and yield more influence in FedCon, politics has to be carefully considered. Sometimes BUs are not willing to share if there are possible overlaps with what they are developing and what is already available in a different BU or at the corporate level. Convincing BUs to work together could be hard and caution has to be taken in which players to involve in development of the EA practice. Additionally, there has to be some sort of collaboration between the EAPMO and PMO for lessons learned and organizational improvements. These high level political criterions are also fulfilled by TOGAF where it recommends how Architecture Governance and Architecture Boards should be setup.

Innovation at FedCon:

Broadly speaking, innovation in organizations is disruptive, incremental or a combination of both. Disruptive innovation as described by the world-renowned management theorist Clay M. Christensen’s institute is such that it “transforms an existing market or sector by introducing simplicity, convenience, accessibility, and affordability where complication and high costs are the status quo.” This disruption can come in the form of unique business models, products and/or services that can give rise to new industries and improve existing industries. On the other end of the innovation spectrum, incremental innovation is where small changes are made to existing business models, products and services to improve existing industries.

Being a US Federal Government contractor, innovation at FedCon is mostly incremental since it tries to improve upon its existing products and services that are provided to the civilian agencies. FedCon accomplishes incremental innovation by obtaining customer feedback and assessing the competitive landscape. However, since BUs only focus on their own expertise, there are less opportunities for collaboration across BUs, which means technology products and services, are being developed without leveraging what already exists in the organization.

The primary innovation concerns in choosing an EA framework are:

  1. Stakeholders – FedCon employees that work directly with customers are the stakeholders that need to be considered since improvement of existing technology products and services are highly dependent upon customer feedback and conveying of the feedback to FedCon.
  2. Domain – In terms of innovation, FedCon is interested in creating technology products and services that meet customer expectations and exceed what the competition can offer.

EA is a disciplined approach to accomplishing enterprise objectives through alignment between business and IT. This disciplined approach can also be leveraged to make FedCon more competitive, which can result in bringing technology products and services quicker to the marketplace. This high-level innovation criterion also point towards using TOGAF since it is constantly being improved upon based on the feedback from technology vendors and solution providers.

Culture at FedCon:

The “father of modern management” Dr. Peter Drucker once said that, “Culture eats strategy for breakfast.” Culture can affect the ability of any organization to adopt or resist changes to the organization. While culture is typically considered a fuzzy attribute of an organization but there are tangible things that we can observe to decipher corporate culture which include (1) corporate values, (2) employee recognition and risk taking, (3) salaries, commission and hourly rates, (4) location, (5) clothes and (6) domain expertise and product/service subcultures.

At FedCon, the culture is such that change is welcomed as long everyone who is affected by it understands its purpose and there is no disruption to normal business processes. This is a two-pronged issue for the selection of an EA framework since even if the value of EA is understood by senior leadership but it is not understood at the BU, program/project and individual levels then it becomes just another information collection exercise.

The primary cultural concerns in choosing an EA framework are:

  1. Stakeholders – FedCon has a process-driven and metrics-monitoring culture. This is one of the reasons that Program Management Office (PMO) is an important part of FedCon since it provides a consistent process by which program/projects can be evaluated. In order to incentivize employees to change their behavior for the organizational transformation, human resources and accounting/finance offices are also stakeholders in EA success.
  2. Domain – Culturally, FedCon is interested in creating an atmosphere that encourages employees to take risks and leverage the massive intellectual property it has developed over the years to stay competitive.

One of the reasons for the success of the PMO within FedCon is its process-driven culture. So for the selection of an EA framework we have to consider what plays into strengths of FedCon. This high level cultural criterion leads us to TOGAF that provides a methodological approach for EA within an organization. The EAPMO would make use of lessons learned from the PMO to create a successful EA practice.

Execution at FedCon:

Intention without execution is simply thoughts without results. An organization can have great intentions but if it does not operationalize those intentions then all the strategy discussions and documentation it did just an exercise in futility.

At FedCon, execution has two views. One view is the execution based on winning a government contract to deliver technology products and services. The second view is execution of the corporate strategy that looks into entering new markets, mergers and acquisitions and creating superior technology products and services.

The primary execution concerns in choosing an EA framework are:

  1. Stakeholders – All employees of FedCon at every level are stakeholders in the successful execution of EA.
  2. Domain – In terms of execution, best practices have to be applied/created for all of FedCon and metrics developed that assess organizational performance.

STANDING UP AN EAPMO:

After assessing the business environment of FedCon to determine an appropriate EA framework, next we have to determine people, processes and technologies needed to standup the EAPMO. These needs are discussed below:

People:

In order to assess the skillsets needed to run the EAPMO, we have to look at the current skillsets available, skillsets that people need to be trained on and hiring of people with the necessary skillsets at FedCon. The hard skills needed to join the EAPMO require the knowledge of the chosen EA framework (i.e., TOGAF) and the ability to find common themes to enhance collaboration. The soft skills needed to join the EAPMO require (1) being politically aware, (2) ability to create bridges/connections and (3) high emotional intelligence. Additionally, metrics will be created to evaluate EAPMO team members based on their hard and soft skills.

Processes:

The business processes followed by EAPMO would be determined by TOGAF best practices and what has worked within FedCon. At a high level this would be the architecture governance process and at the lower lever this would the cross-functional teams processes for being advocates and collectors of information across FedCon. The various processes would be tested in the first 6 months to work out any wrinkles and get a baseline understanding of what needs to be done.

Technologies: 

Now that we have selected the FedCon’s EA framework to be TOGAF, we have to select a tool that supports this framework. This tool can be selected by looking at Gartner’s Magic Quadrant for Enterprise Architecture tools.

 

CONCLUSION:

Due to FedCon’s expertise as a technology company and for all the reasons stated in the analysis section, TOGAF is the right EA framework since it provides a roadmap of what needs to be done. One thing to keep in mind is that a framework needs to be flexible enough so it can adapt with changing organizational needs rather than the organization becoming a slave to the framework.

References:

  1. Khan, Arsalan. “5 Factors for Business Transformation.” Arsalan Khan. WordPress.com, n.d. Web. https://arsalanakhan.wordpress.com/2013/07/16/5-factors-for-business-transformation/
  2. “Stakeholder Management.” ADM Guidelines and Techniques – Stakeholder Management. TOGAF, n.d. Web. http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap24.html
  3. Schekkerman, Jaap. Enterprise Architecture Good Practices Guide: How to Manage the Enterprise Architecture Practice. Victoria, BC: Trafford Pub., 2008. Print.
  4. “Architecture Governance.” Architecture Governance. TOGAF, n.d. Web. http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap26.html
  5. Christensen, Clay M. “Christensen Institute.” Christensen Institute Disruptive Innovation Comments. Christensen Institute, n.d. Web. http://www.christenseninstitute.org/key-concepts/disruptive-innovation-2/
  6. “The Business Executive’s Guide to IT Architecture.” The Open Group Architectural Framework (TOGAF) Executive Overview. TOGAF, n.d. Web. http://www.opengroup.org/public/arch/p1/oview/
  7. Caldbeck, Ryan. “Why Execution Is Everything In Business.” Forbes. Forbes Magazine, 16 Sept. 2014. Web. http://www.forbes.com/sites/ryancaldbeck/2014/09/16/why-execution-is-everything/
  8. “Organisational Culture Eats Strategy for Breakfast and Dinner.” ORGANISATIONAL CULTURE EATS STRATEGY FOR BREAKFAST, LUNCH AND DINNER. Meliorate, n.d. Web. http://www.torbenrick.eu/blog/culture/organisational-culture-eats-strategy-for-breakfast-lunch-and-dinner/
  9. Lapkin and Weiss. “Ten Criteria for Selecting an Enterprise Architecture Framework”. Gartner report G00163673. Gartner http://my.gartner.com/portal/server.pt?open=512&objID=260&mode=2&PageID=3460702&resId=838915&ref=QuickSearch&sthkw=G00163673
  10. Brand, Saul. “Magic Quadrant for Enterprise Architecture Tools.” Gartner report G00263193 http://my.gartner.com/portal/server.pt?open=512&objID=260&mode=2&PageID=3460702&resId=2859721&ref=QuickSearch&sthkw=ea+tools+magic+quadrant

5 Questions to Ask About Gamification

The term gamification refers to “the use of game design elements in non-game contexts.” (Deterding et al.) The non-game contexts imply that gamification is different than games and can be applied to society, business, technology and individuals at various levels. Gartner goes a step further and defines gamification to be “the use of game mechanics and experience design to digitally engage and motivate people to achieve their goals.” Essentially what this means is that gamification is used to change the norms, attitudes and habits of individuals and organizations from a current state to a desired future state typically through the utilization of technology. Generally speaking, the use of gamification in the organization can be categorized into external uses (e.g., customer engagement) and internal uses (e.g., employee engagement).

In order for organizations to effectively leverage gamificaition as a game changer, they have to ask the following questions:

Currently

In the Future

Who is using gamification externally and internally? Who should be using gamification externally and internally?
What is gamified? What should be gamified?
Where it is being used? Where it should be used?
When are gamified types of activities are happening? When should gamified types of activities be happening?
5. Why it is becoming a competitive advantage? Why you should be using it as a competitive advantage?

When you are asking the above questions across all levels of the organization, here are few things to keep in mind (1) have clearly defined goals for the players/users and the organization, (2) blindly applying gamification without thinking through organizational repercussions can be costly, (3) measure progress, get feedback and iterate, (4) create value since it is a not a one-way street but a multi-way street and (5) balance between intrinsic considerations and extrinsic rewards.

Here organizations have a choice about gamification as a (1) passing fad or (2) as a strategic lever that can help them transform. So, the real question about using gamification becomes, “Can you afford not to do it?”

Gamify SPICE

Gamify SPICE

References:

  1. Sebastian Deterding, Dan Dixon, Rilla Khaled, and Lennart Nacke. 2011. From game design elements to gamefulness: defining “gamification”. In Proceedings of the 15th International Academic MindTrek Conference: Envisioning Future Media Environments (MindTrek ’11). ACM, New York, NY, USA, 9-15. DOI=10.1145/2181037.2181040 http://doi.acm.org/10.1145/2181037.2181040
  2. “Gamification – Gartner IT Glossary.” Gartner IT Glossary. Gartner, n.d. Web. http://www.gartner.com/it-glossary/gamification-2/
  3. Werbach, Kevin. “Coursera – Gamification.” Coursera. Coursera, n.d. Web. https://www.coursera.org/course/gamification
  4. Krogue, Kevin. “5 Gamification Rules From The Grandfather Of Gamification.” Forbes. Forbes Magazine, n.d. Web. http://www.forbes.com/sites/kenkrogue/2012/09/18/5-gamification-rules-from-the-grandfather-of-gamification/
  5. Stanley, Robert. “Top 25 Best Examples of Gamification in Business.” Clickipedia. Clickipedia, 24 Mar. 2014. Web. http://blogs.clicksoftware.com/clickipedia/top-25-best-examples-of-gamification-in-business/
  6. Kleinberg, Adam. “Brands That Failed with Gamification.” – IMediaConnection.com. – IMediaConnection.com, 23 July 2012. Web. http://www.imediaconnection.com/content/32280.asp

 

SOA Migration Case Studies and Lessons Learned – A Critical Review

Service Orientated Architecture (SOA) is a framework that allows business processes to be highlighted to deliver interoperability and rapid delivery of functionality. The benefits of SOA include reuse of generalized services, reduce costs and better business and IT alignment. If done correctly, it helps an organization respondent to ever-changing business needs efficiently. If done incorrectly, it can create bureaucracy and silos. This article evaluates the decisions, assumptions and conclusions made by the research paper, SOA Migration Case Studies and Lessons Learned.

In the research paper, two research and evaluation methods are used to assess different cases for SOA. The first method is the Case Study Method where the researchers develop a theory and based on that theory they develop criterions to select the case studies that will be assessed. This Case Study Method is shown below:

Case Study Method

Case Study Method

The second method uses a customized version of the Evolution Process Framework (EPF) to evaluate SOA. This customized version is called EPF4SOA and the phases involved in the evaluation are shown below:

EPF4SOA Phases

EPF4SOA Phases

With the research and evaluation methods in place, the research paper goes on to assess three multibillion-dollar organizations that have been around for at least 50 years. These organizations have legacy systems that have become archaic and thus they are unable to respond to rapidly changing business needs. Keeping these limitations in mind, these organizations go on the path to extract as much functionality from these legacy systems as possible by creating SOA services that could be used in the organization. Based on the EPF4SOA, the research paper goes on to claim that for effective SOA migration, organizations need to have a strong business case, services design, technology selection, SOA governance and education and training.

As we read this report, it seems obvious that the researchers have done a good job of evaluating these large organizations from the finance and telecommunications sectors and in highlighting the lessons learned on SOA migrations. However, this research has made some decisions and assumptions that need to be understood. Firstly, in the Case Study Method, there seems to be an element of confirmation bias when the cases being selected are based on an initial theory. This confirmation bias can lead to selecting cases that fit what the researchers are looking for rather than selecting cases and then determining what theories can be derived from those cases. Secondly, the research looks at organizations that have been around for a long time and by their very nature are most likely to have legacy system issues and make the assumption that other organizations would have the same issues. Lastly, the research report alludes to that SOA can help in business and technology alignment but does not take into account strong leadership and organizational change management capabilities that are needed for SOA migrations.

Keeping the above in mind and carefully reading the case descriptions, we can extrapolate that there might be some potential challenges in the cases being presented in this report. These potential challenges are explained below:

  1. SOA is not only an IT concern: One of the lessons learned in this report indicates the need for a strong business case for SOA developed by IT in order to get management support. The fundamental problem with this lessons learned is that it automatically puts the burden of implementing SOA across the entire organization on IT and takes it away from the business-side’s responsibility and involvement with SOA. While IT is responsible for creating SOA services but business has to work collaboratively with IT. Business has to understand how the organization came to a point where it became difficult for quick system changes and how to avoid situations like this in the future. Thus, SOA is not only an IT issue but an organizational endeavor that involves all parts of the organization as well.
  2. Organizational processes need to be reevaluated: One of the cases mentions the presence of too many point-to-point integrations that is reducing the ability of the organization to be more agile. While this might be the case but there is a bigger prospective here that is missing. This perspective revolves around organizational processes in place that led to this in the first place. These organizational processes not only entail IT but also the business side. It seems like in this case IT would do what businesses ask them to but there has to be some mutual understanding that the requests have to be understood holistically. Even after a SOA migration, if these organizational processes are not optimized they might still result in ad-hoc requests from the business leading back to point-to-point integrations.
  3. Long-term view on legacy systems is needed: The cases in the report indicate that replacing the legacy systems was not an option since it would be costly to do this. While in the short-term this seems like a good idea but in the long-term there are issues with this approach. These issues entail the constant “patching” to upgrade underlying hardware and software in addition to overburdening legacy systems where new services are being added on top of systems that should be replaced rather than being continued to extend their end of life. While for some organizations it might not be possible to replace legacy systems altogether but there should be a plan to retire these systems with new systems eventually.
  4. No measurements means no ROI exists: While some organizations in the research report did measure SOA migrations ROI but that was done after the fact. So, if the organizations were not measuring pre-SOA how would they know if what SOA migrations promised is what the organization was able to achieve. Herein lies the problem where quantification and justification is made to show SOA being a success without doing the due diligence before embarking on the SOA journey.

In addition to the above identified problems, the research report does not put enough emphasize on the importance of governance that is needed for SOA. Lets explore what is governance and why it could be one of the differentiating factors in SOA migrations.

Governance: Governance is the policy of how things should be done and provides a framework in which business processes can operate under regulatory, time and other constraints. Thus, governance is an organizational responsibility even for SOA and not only an IT one. In order to accomplish this, a governance board should be setup that consists of a cross-functional team from both IT and business. Additionally, governance should not only include the overall organization and management of SOA activities but also creation of success and failure measurements. These measurements should be used to actually determine the state of SOA within the organization instead of people doing vaporware measurements that have no grounds in reality.

In conclusion, while the research report is interesting in its own right but it should not be taken as the only lessons learned for successful SOA migrations. Based on a few cases these lessons learned cannot be applied across various organizations such as smaller organizations, governments and nonprofits but should be taken with a grain of salt. The lessons learned should be a start but not the bible for successful SOA implementations. A successful SOA implementation will depend upon context, processes, technologies and people since broadly speaking SOA is an organizational change management journey.

References:

1. SOA migration case studies and lessons learned

What’s Wrong With My Enterprise Architecture? – a response

Recently, a fellow Enterprise Architect reached out and asked my opinion on his article.  Below is my response:

• Enterprise Architecture has many definitions. Here is one that I tried to create in 160 characters. “EA bridges business and IT via enterprise integration/standardization resulting in people becoming more efficient and effective in achieving their objectives.”

• While there are many reasons behind failures of EA within organizations but as I see it, they essentially boil down to only one thing (i.e., lack of communication in understanding the true value of what EA brings to the organization). It takes effort from everyone (EA, Business and IT) in the organization to use EA for business transformation. Before anything else organizations need to decide:

  • Why they need/want EA? Here is a good video that alludes to this.
  • What quantitative and qualitative values does EA bring to the table?

• Unfortunately EA has turned into merely an information collection activity and moved away from why this information is being collected in the first place. What is the strategic intent? In my observation, most EA is not strategic (e.g., Federal Government’s use of EA)

• My biggest issue with EA these days is where it resides within the organization. These days EA reports to or is a part of IT and suffers the same fate as IT (e.g., reduced budgets, no executive representation etc.). Ideally, EA should report into Chief Strategy Officer (CSO) or Chief Executive Officer (CEO) but not to the Chief Information Officer (CIO) or Chief Technology Officer (CTO).

• EA is a conceptual mindset. In my view, it is not about frameworks, modeling or programming languages. EA is about business transformation that may or may not require IT to accomplish transformation. Blasphemy! I know ☺

• True EA is difficult to do and it takes a long-term commitment from the organization to pursue it.

In today’s business world quickness and agility is often used as a pretext/excuse for a lot of things mostly because the people using these terms just want additional lines added to their resume before they move on. To put in an analogy, what kind of car would you like to drive? One that goes really fast but has bare minimum safety or one that has optimum safety but you might get it a month late? Short answer is, it depends. Mainly it depends on what is the end goal the organization or person is trying to achieve. Same is true for EA. Without measurable end-goals EA just becomes a complacent black hole.

Chief Executive Officer and Information Technology with sprinkles of Enterprise Architecture

A few weeks back I posted an article (Why IT Should Be on the CEO’s Agenda) on the Massachusetts Institute of Technology (MIT) LinkedIn group about why Information Technology (IT) should matter to the CEO. A reader commented and referred me to his blog post. After reviewing his post, I have the following responses:

  • I would argue the perception that IT is too complex and decision makers need to have a deep understanding of IT in order to leverage it. For most organizational decision makers, simply recognizing that IT can be leveraged for competitive advantage can be sufficient to have a leg up over competition. Think about it, although the CEO might have a high-level understanding of Finance, Accounting, Operations and Sales but does s/he needs to be an expert in all of them? Absolutely not and similarly CEO does not need to have a deep understanding of IT although the better understanding s/he has, the better equipped s/he will be to face the challenges of the future.
  • On the point that IT has “complex processes and structures” is a blanket statement and would not apply to each and every organization. I would say that it all depends upon the organization and careful review should be done to understand the reasons for the existence of these processes and structures. This review can help in improving the organization and create an appreciation for all sides.
  • In terms of Enterprise Architecture (EA),
    • it has many flavors to it but it almost always starts with strategy/analysis and should result in execution/operations. While EA cannot predict each and every scenario that can happen but by involving the people who are doing the day-to-day operations, EA is able to create concrete solutions that work in the real world and is not merely theory.
    • one of the biggest mistakes organizations make is that they think EA is only an IT-thing, only about artifact development, only about future planning and only about software application development. While all of these are noble pursuits, EA has a much broader view of the world that goes beyond the IT world. A well-run EA practice will consistently produce qualitative (e.g., management best practices, better communications etc.) and quantitative (e.g., increased productivity/sales, cost savings etc.) benefits for both IT and business. So, EA sits in between IT and business and whenever you limit it to an IT-thing then it defeats the over arching purpose of EA.
    • organizations already “do” EA, no matter what they call it, how broken it is and no matter if they use custom or industry frameworks to capture the information. Each framework has its pros and cons but organizations simply cannot put the blame on EA when the business itself is not aware of how it can leverage EA across the organization.
    • since EA is the highest level of abstraction, it looks at the business and IT sides holistically and is used to drive various objectives such as organization change, business intelligence and portfolio management to name a few. It is up to the organization collectively to understand this and then help themselves to continuously improve organizational assets such as people, processes and technologies.

I hope the above response helps shed some light on the different things that organizations need to consider. I would leave you with some questions to think about?

  • Does the organization really know what it wants to be when it grows up?
  • Does the organization really know who it wants as friends?
  • Does the organization really know what house it wants to build?