Question

PLS DO NOT ATTEMPT THIS QUESTION IF YOU ARE NOT GOING TO COMPLETE IT.

NO PLAGIARISM

MINIMUM OF 400 typed words and not written on a piece of paper.

1)Compare and contrast an organization and an enterprise.

2)Using the scenario, please provide the following:

a. What should structural and cultural aspects be captured by this Enterprise Architecture (EA) program?

b.Who are the potential stakeholders for this Enterprise Architecture program?

c.What could strategies for gaining stakeholder buy-in be used?

Answer 1

The terms organization and enterprise are often used interchangeably. However, they are actually quite different. As a small business owner, your company is both an enterprise and a formal organization. Organization is essentially an umbrella for all types of business and social entities with multiple members in pursuit of a common goal.

Organization Basics

People get together in pursuit of many shared objectives. For example, a handful of friends that form an organization when they start a social club. A community committee formed to plan an event is also a formal organization. All enterprises are also organizations. Another perspective is that organizations are affected by both internal and external influences. The interaction of the people in the organization and input, plus interaction with or response from external people and events impact organizational activities.

Formal or Informal

Organizations have structure and leadership. A formal organization has a formal leader and structure. A leader may be called a president, manager, supervisor or chairman. An informal organization has elements or structure, but no formally designated leader or reporting relationships. Employees that meet in the company break room every day for lunch form an informal organization. The organization has a loose structure in that the meetings take place around the same time in the same place. While the organization wouldn't have an official leader, more dominant members would likely direct the conversation.

Enterprise Basics

An enterprise is a business-oriented organization formed specifically so founders can pursue entrepreneurial endeavors for a profit. While enterprises have social elements, they are different from clubs or other non-commercial organizations because of their entrepreneurial purposes. You start an enterprise for the purpose of attracting customers, selling goods and services and earning profit. The formal structure in a business establishes reporting relationships between managers and employees and across company departments.

Formal vs. Informal

Enterprises are also either formal or informal. The term enterprise is more commonly used in reference to informal entrepreneurial activities. When a 10-year old girl sets up a lemonade stand in her neighborhood, she has formed an enterprise, or an informal business. Any type of sole proprietorship is considered an individual's informal business because you don't set up a legal business entity. Formal enterprises include partnerships, S-corporations, limited liability companies, corporations and joint ventures.

Answer 2:

Enterprise Architecture is seen as a business discipline that is involved in architecting the enterprise, including its organizational structure and processes, as well as the IT to support it. I have seen organizations that do this, and where the EA team is reporting up to business leadership separate from the IT organization. I think this is the 'ideal' positioning.

The more classical scenario for EA is where the team is part of the IT organization, reporting to the CIO, who may or may not be on the Board - many still report to the CFO or the COO. The scope of EA is still that of business, information & applications and technology, however in most cases the focus is more on the business systems planning side.

I have even seen variants where there is a Business Architecture team outside of IT with its own reporting line to the Board, collaborating with an EA team that is reporting in IT. This is something in between the two scenarios above.

This variety of positioning of EA and the EA team has an impact on what EA means in an organization. And where I said that this first example is 'ideal' maybe I should reconsider. This positioning is only ideal if the organization is not only giving EA the position and task, but also truly expects EA to do this architecting, and is ready to take over most proposals of EA. EA can only be impactful if business leadership integrates EA in their process. If this is not the case EA will be in its ivory tower, making paper tigers, until someone discovers that it is too expensive to maintain such organization with little or no impact.

You may argue that the classical type of EA is not 'true' Enterprise Architecture, and see it more as high-level solutions architecture ….. but in that case I think there aren't many 'true' Enterprise Architects. For me this is semantics. I'm cool with calling anyone an Enterprise Architect, who is tasked to see the big picture of (part of) the business landscape, Information & applications portfolio, and technology landscape, and the portfolio of programs and projects involved in the alignment of that with business strategy evolution.

Anyhow, I think that in most organizations EA is not doing the truly transformative part of architecting. That is the prerogative of business leadership: they are tasked to think about the future of the organization, its products, services, markets and customer segments, mergers, acquisitions, disinvestments, etc.. EA has a role to play there, but in most cases not at the steering wheel. As trusted advisors EA may make recommendations on strategy based on their understanding of the business and the market. And for sure in any case EA is involved in assessing all the implications of decisions taken by leadership - if EA's lucky proactively, but in many cases reactively. And finally EA has a role to play in the design and planning of the implementation of strategic decisions.

What is more important than the exact positioning of EA and the EA team is whether the team is able to be of value to the organization. Positioning has some influence there, but I believe that culture is far more important. I believe that EA's who want to be effective need to pay attention to culture just as much as they pay attention to strategy.

What is culture?

We can look up all kind of definitions of culture, but I am not doing that. I will describe here what I think are essential aspects of culture and what are the implications for Enterprise Architects.

Culture can be recognized in sets of collective views and behaviors, or behavior patterns, emerging when you segment people according to criteria like country, region, religion, political views, sports, company, and so on… Typically you are part of several of those segments and you aggregate influences of the related cultures in your being. Cultures are drivers of the way we look at the world, express ourselves and behave - unconsciously - next to factors like personality, circumstances, etc.. I for instance am Dutch, I play field hockey, I am a scientist and Enterprise Architect, and all of those have some influence on my views and behaviors: I am quite egalitarian and have a direct style of communicating, think soccer is an old fashioned sport for overpaid athletes who cry over every small pain, I let facts trump feelings, and I passionately believe it matters to look at the big picture of business, information & applications, and technology. Cultures are not static, they tend to change slowly. Through your behavior you influence cultures as much as your behavior is influenced by them.

Organizational culture

Membership of an organization is one way of segmenting people, and yes, organizations have cultures. What drives organizational culture is partially elusive, it is what emerged, but sometimes you can recognize influences like national culture(s), type of product/service/customers-combination, personalities of leadership, specific (traumatic) events in company history, etc.

What's in it for Enterprise Architects?

Enterprise Architects who study company culture can have some big advantages in terms of greater impact (= value for the organization). Important aspects influenced by culture are how organizations deal with strategy, organizational structure and hierarchy, the way decisions are made, etc. Below I will share my views on several of those.

Dealing with strategy

The assumption Enterprise Architects live under is that organizations have a strategy. However, what that strategy is, is not always clear. And what the role of the strategy is, is not always clear as well.

To know the strategy, EA's need to combine several approaches.

First of all they can go look for the deliberate and explicit strategy as can be found in strategy documents, strategy statements on websites (intranet, internet), annual reports, shareholder briefings, etc. In larger corporations EA's should pay attention to the organization structure and look beyond what is there at corporate level, e.g. divisional, country level.

Secondly, they can look at the decisions an organization makes, for instance by looking at the business and IT project portfolios. By seeing where decisions are clearly influenced by the documented strategies, and where sometimes decisions are contradictory you can see how serious the organization leadership takes deliberate strategy. You will see to what extent documented strategy is a true guide for the evolution of the organization, and which parts are mainly window dressing.

Also, out of those decisions patterns may emerge that demonstrate certain business principles and evolutions that are not explicitly documented, but that apparently do guide where the organization is going to. This is the emerging strategy.

By making a synthesis of the documented strategies, the delivery on those strategies, and the emerging strategies, and feeding this back to business leadership, you create a working basis for your EA work. And if the organization culture allows it, you get a chance to provide valuable feedback to business leadership.

Organizational structure and hierarchy

As discussed above, the positioning of EA matters. The extent of this depends on how organizations deal with organizational structure and hierarchy.

Organizations can be complex: multiple product/service divisions, multiple customer segments, powerful staff departments, deep hierarchies. For EA organizations working at the corporate level it really matters what the position is of product divisions and corporate staff department is. Is this a bunch of more or less independent organizations with little overlap. Where is power to make decisions independently: at the center, at division level, or may even at departmental level? This matters a lot, for instance if EA sees a great benefit in setting up cross-divisional platforms or standards. The way to get support for such decision differs a lot if an organization is centralistic or federated.

When collecting information, or providing advice, how does hierarchy matter? Can you simply step in someone's office or do you need to abide to some conventions on who you can directly contact or not. Can you afford to freely express your opinion in front of leadership? All that depends on culture. Sometimes this is national culture. I personally have worked with managers from The Netherlands, USA, UK, Germany, France, China - successfully - and have seen that some of the behaviors of them was stereotypical for their countries, like I expect that they every now and then have thought of me as a typical Dutchman.

Being sentient of corporate and national cultures around structure and hierarchy will let you get information and deliver your message more effectively.

Decision making process

In many organization there is some kind of formalism around decision making - especially in case of investment decisions. Knowing this is important, but may not be enough to get the decisions you think from an EA standpoint are in the best interest for the company.

For instance where the planning process in most organizations is formally top-down, very much in line with how EA likes it, the reality is that there are often also strong bottom-up forces. I have worked in organizations where the culture was that management considered the IT landscape low priority, and though formally taking all decisions, de-facto delegating this to whoever in the organization they trusted and cared about IT.

EA's who are sensitive to cultures around organizational structure, hierarchy and decision making process, make stakeholder maps that recognize this. Through this you can be far more effective in not only being right, but also getting the right decisions.

Perspective

For Enterprise Architecture to be effective, you need more than the right assignment and reporting line. Understanding corporate culture can be as important, to fully understand the business strategy, know how to deal with organizational structure and hierarchy, and to get decisions taken.

Ultimately Enterprise Architecture and the EA team will only survive if EA adds value to the company. This value is measured by how EA influences change in business and its supporting IT.

Answer 3:

EA stakeholders are individual or grouped representatives of the organization who are affected by EA products, either by providing input to EA decision making or having to conform to the EA products. Typical EA stakeholders are senior management, program and project managers, software architects, and enterprise architects. Based on their specific role within the EA function, the organizational level at which they operate, and the aspect area they focus on, EA stakeholders actively pursue specific objectives. These objectives are potentially conflicting, and may not help to meet the organizational objectives. However, regarding the attributes of the products and the services of the EA function, each stakeholder expects these to help achieve their goals. We used the key SA stakeholder roles described by Smolander et al. as a basis to create a 4 by 4 matrix of EA stakeholders shown in Table 1. The columns represent the four EA aspect areas and the rows represent the four organizational levels. We omitted the architect role in Table 1, since we focus on the other EA stakeholders in this article. Architect roles exist at the various organizational levels, and have one or more aspect areas of responsibility – e.g., enterprise business architect or project application architect. B. van der Raadt, S. Schouten, and H. van Vliet At enterprise level, general management is responsible for EA decision making regarding the target enterprise architecture. This involves creating a strategy for the aspect area these stakeholders are responsible for. The board, responsible for the enterprise business strategy, typically consists of the Chief Executive Officer (CEO), Chief Financial Officer (CFO) and the Chief Operational Officer (COO). The Chief Information Officer (CIO) is responsible for business and IT alignment, i.e. that IT supply meets business information demand. Therefore, the CIO is concerned with both information and IS aspect areas. The Chief Technology Officer (CTO) is responsible for decision making regarding technology components and platforms.

Domain level EA stakeholders are typically domain owners and change managers that coordinate (i.e., portfolio manager) or manage (i.e., program managers) change programs within that domain. Within the business aspect area, a domain owner is the head of a Business Division (BD) or Business Units (BU), who is responsible for the operational performance of his/her domain. Like the CIO, the Division Information Officer (DIO) is responsible for the business and IT alignment for a specific business domain, and therefore focuses on both information and information systems aspect areas. Within the TI aspect area, the platform manager is responsible for the operational performance of the platform or infrastructure domain. The platform subject matter expert guides all changes on that platform or domain.

At project level, EA stakeholders are responsible for running projects and implementing high impact changes into the operational environment. For example, the business project manager is responsible for delivering, within fixed time and budget, a solution that fits the business requirements. The business process designer is responsible for determining the requirements and design of the solution. An information analyst determines the information requirements and creates a database design accordingly. The project managers in the IS and TI aspect areas manage the projects that develop the software applications and infrastructure components. The software Stakeholder Perception of Enterprise Architecture designer creates a design that realizes the functional and non-functional requirements. The infrastructure engineer configures infrastructure components based on the infrastructural requirements of the software application.

EA stakeholders at operational level are responsible for the stability and continuity of the operational environment. The operational (business, application or data center) manager is responsible for day-to-day operation and reporting. Business process engineers and data, application, and infrastructure administrators perform day-to-day maintenance and improvement activities to optimize continuity and stability.