Enterprises as Structures

Dragon1, as a method and framework, is designed to drive innovation and change within enterprises. Therefore, the better understanding you have, as an architect (the designer of total concepts), of the current state of the enterprise and your vision on the future state of the enterprise, the better you can create architecture designs for owners/clients and supervise their realization.

The architecture of a structure is the total concept of a structure.

A structure has three dimensions: construction, operations, and decoration. This applies to building structures and landscapes as well as enterprise structures. An enterprise can therefore be viewed as a structure.

An enterprise has a constructive dimension (segments, markets, organization, departments, etc.)

An enterprise has an operative dimension (business, processes, etc).

An enterprise has a decorative dimension (image, identity, transparency, process flow hiding, data hiding, etc.).

Because an enterprise can be viewed or seen as a structure, it can be designed and constructed just like any other type of structure in building architecture and landscape architecture.

As an enterprise architect, one wants to find the concepts that best answer the stakeholders' requirements and strategy and implement them.

An enterprise consisting of one or more businesses that are responsible for the execution of its activities is a conglomerate of many activities, such as processes, products, services, people, systems, and infrastructure.

An integral approach of an Enterprise as a Structure

Figure 1 provides an exploded view of an enterprise comprising many entities.

When an architect designs a structure to be part of an enterprise, as shown in Figure 1, he must consider the entities presented in this example. The solution designed by the architect to meet a set of requirements and enterprise objectives typically consists of a business section, which includes processes, employees, services, and products, and an IT section, which encompasses information systems, networks, and computers.

Dragon1 prominently recognizes integral business and IT solutions, as increasingly enterprise solutions consist of combinations of business and IT entities.

A mistake often observed in the '80s and '90s was that certain IT projects ignored the effort needed for business entities to change along with the other technological changes. In some cases, this resulted in failed introductions of entire computer systems that could not be operated or remained out of commission.

Architects create models of the enterprise, the environment, and the structure. All three models are then combined into a harmonious entity. The model of coherence in architecture clearly explains how this is achieved. Within the confines of large enterprises, the environment of a structure often requires various levels of complexity.

The Coherence in Architecture model includes an example of cooperation between the environment, the enterprise, and the structure. We perceive an enterprise that is internally and centrally controlled. When an architect designs a human resources or financial information system, they must consider vision, strategy, architecture, rules, and policies, not only for the business in question but also for the internal and external control of the enterprise. If the architect does not take this into account at all, or insufficiently, the introduction and utilization of the system will cause problems or even prevent the system from being commissioned.

Or, if an IT department has certain rules concerning the procurement of solutions, it is a given fact that if this is policy, the procurement department has to act accordingly. IT rules will apply if a procurement department requires new IT support and is subject to the policy. It proved that everything in an enterprise is interdependent and follows a theory known as contingency theory.

The architect needs to employ a wider perspective than merely business activities and IT to create realizable architecture designs.

Structure

An architect has a core task: to create an architecture design of a structure, based on stakeholder requirements and strategy. Within an enterprise, a structure typically comprises a combination of business and IT entities, including information systems and other relevant components. Integral solutions such as CRM include renewed business processes, such as sales and information systems on supplier contact, history, and ‘Name, Address, City’ information administration.

These integral solutions form a coherent set of entities. As such, it is essential to view them as structures that can and will be utilized for some time, and even expanded, replaced, or renewed without causing disruption.

By regarding an integral solution as a structure and, as such, consisting of various building components, architects, independently from each other, can perceive the structure’s construction design, operation aspects, and decorative aspects, or the individual building components belonging together. This also enables architects to design each aspect independently.

If this is still too complex, the structure can be divided into building blocks, or its specific problems can be treated as fragments and mapped. This way, problems can then be individually solved.

The Structure model includes an example of which entities constitute a structure. Some structure entities constitute construction, others constitute operations, and others constitute decoration. This distinction explains the three functional types of a structure.

Examples of a structure’s constructive entities are components that provide a framework for strength, resilience, and division in an enterprise, and they provide a platform for agreements, business rules, strategic starting points, system perimeters, domain perimeters, policy frameworks, supervision, and enforcement.

Operative entities are often considered facilities in a structure. They represent a specific, meaningful utility function to a structure’s users. Constructive entities do not possess this feature or have it in an indirect way, or hardly at all. Constructive entities are of little to no operational importance to customers and employees in terms of product and service usage. Operative entities inextricably connected to a structure are infrastructure or infrastructural facilities.

When it comes to building architecture, everyone immediately has a particular image of a structure’s decorative functions or the decorative functions of a structure’s entities. When it comes to an enterprise, an image is not often perceived automatically despite an enterprise’s certain decorative elements. Take, for instance, a program that showcases an enterprise’s identity, motivation workshops, and the design of its workplaces, as well as the image presented on an enterprise's or information system's website, illustrating how it is structured, segmented, or operates.

Because an enterprise can be compared to a structure, the architect can distinguish a structure’s aspects and dimensions as singular and separate entities. By taking them singularly, the architect can design them as separate entities and, in theory, create a constructively, operatively, and decoratively attractive enterprise.

An architect designs integral business and IT solutions using architectures, described as structures, often consisting of business processes and information systems divided across different domains. The architect must create at least five models to provide the client with a maximum of solution possibilities:

1. A structure concept model
2. A structure element model
3. A structure component model
4. A structure object model
5. A technical structure product model

Also, the architect creates combinations and integrations of the above-mentioned structure models. The architect also includes various visualizations and perspectives, such as a combined and integral view of a model's environmental entities and the constructive, operative, and decorative entities. This combines communicating with stakeholders and testing if the solutions will lead to the preferred model. For each model, the architect also includes a meta-model.

If a structure or solution includes definable, reusable composite parts of elements, components, objects, and technical products, it pays to recognize these as building blocks. A building block enhances the reusability of entities and hides the complexity that lies behind it. Needless to say, a building block must be carefully documented.

Enterprise views and perspectives

Dragon1 differentiates in the way an architect views an enterprise. The architect could view one aspect or many different aspects. If the architect looks at one aspect, it is called a side ‘view’. If he looks at different interrelated aspects simultaneously, we call what he sees a ‘perspective’. In this page, we cover different common side views and perspectives.

The Enterprise views and perspectives model shows an example of which common views of an enterprise Dragon1 recognizes: the business process view, the business function view, and the department view. A business process view only shows business processes and their inter-relationships. Business processes, functions, and departments are common administrative elements, i.e., logical elements often applied in an enterprise.

We could also consider logical entities as concepts, in which case we not only look at business processes in the case of business processes, but also at elements and components which constitute the business process concept, such as the business activities. When it comes to viewing different elements and components of a business process, we refer to a business process perspective.

We speak of an information system view and perspective. An information system comprises all applications, personnel, and documents. Consequently, it consists of different aspects that can be viewed, and therefore they also become visible.

Business process perspective

An enterprise business process perspective allows the architect to see the organization, structures, and decomposition of the enterprise’s activities regarding business processes, work processes, process steps, activities, tasks, and actions. The architect becomes aware of how work is organized in the enterprise. This produces a total that is not bound to any organizational format or specific competencies. This way, the enterprise can be designed independently of departments and staff.

Business function perspective

The enterprise business function perspective allows the architect to see the organization, structures, and decomposition of business functions and staff. This produces the total of requirements in terms of knowledge, ability, skills, and competencies to enable work to be executed in the enterprise. In reality, the perspectives of business function and process are linked together. The architect must, however, allow the business process perspective to take precedence over the business function perspective. The reason is that, in terms of how something is executed, a business process constitutes a more concrete organization than a business function.

Department perspective

An enterprise department perspective allows an architect to see the organization, structures, and decompositions of locations and spaces where work is being executed. This perspective is currently often omitted, although it is nevertheless important to view the shortcomings of the current and future organizational situation. This perspective, however, must not lead ahead of the business process perspective. A department is an even more concrete organization than a business process.

Business IT perspective

Besides the perspectives above, an enterprise acknowledges a new perspective: the business IT perspective. This perspective illustrates the dependencies on activities such as conducting business, dealing with, and working within the enterprise's operations. This perspective provides a decomposition of integral business IT solutions within the enterprise, identifying which business activities depend on which IT activities and what IT contributes to innovation.

This can be an eye-opener for many people. Suppose an architect can make it clear to the owners of business processes to what degree their processes depend on the efficient operations of information systems. In that case, they are often taken aback by the explanation and usually take more notice of the importance of enterprise IT operations.

Operating model

Due to the increased interest in the ‘operating model’, we hereby note that an operating model exists when the aforementioned enterprise perspectives are all modeled together.

The integral Business IT solution as an Architecture Structure

When an architect views the integral business IT solution as an architectural structure, significant benefits can be gained.

Business IT alignment

An integral solution is the perfectly aligned total of business and IT entities. The ideal alignment is referred to as business-IT alignment. The architect must be aware of an enterprise’s mission, vision, and objectives to achieve optimal alignment between business and IT entities. The architect will then be able to innovate at a business suitably and IT level.

The Business IT alignment model provides an example of how strategy ensues from mission, vision, and objectives and how strategy directs innovation. This means that new IT options should lead to new perspectives at the board and directors’ level before adapting the vision and objectives in which new IT options are used. This alignment model enables business management to maintain control over IT, while IT remains in support of management.

To achieve the realization of objectives, changes are sometimes needed. For this purpose, organizations will use specific instruments, programs, and projects. A proper relation and breakdown of objectives are preconditions to ensure the integrity of required changes, solutions, programs, and projects. This will ensure that only approved IT options are used within missions, visions, and strategies. Figure 5 illustrates the relationships a business requires to control and manage IT, rather than the other way around.

Also, the architect needs to package his design through a program management perspective to indicate which parts of the design, in which program and project, must be developed separately or integrally. The architect hereby assures that the risk of design failure is reduced when part of the solution is not realized promptly.

Example The Connected Enterprise

Today, enterprises are becoming increasingly complex because of technological progress, like the availability of the Internet and the worldwide convenience of telecommunication. They are changing every second of the day.

This brings opportunities, but it also brings challenges: how to keep the complexity and the changes of the enterprise under control so it stays adaptive?

There is not a day that an enterprise is the same. It is constantly changing. Together with other enterprises or parts of other enterprises, your enterprise is forming chains and networks to produce goods, products, and services, and deliver them through distribution networks to consumers, clients, or other parties in the supply chain.

Examples of connected enterprises are Coca-Cola, Toyota, and Google. It is interesting to see how they compare on certain attributes:

• They are all enterprises: investors put a lot of money into it, many risks are involved, and high ambitions are tried to be realized.
• Their enterprises consist of businesses: producing and selling soft drinks, producing and selling cars, maintaining a searchable digital library, and selling advertising space on it.
• Their businesses are carried out by organizations: in this digital age, they still have headquarters and offices where people work together.
• They all are connected: they are not doing business in isolation. Of course, they collaborate closely with other enterprises.

Dragon1 promotes working towards a connected enterprise, as any enterprise or business will benefit from an optimally connected one.

In practice, many enterprises have three or more businesses (and business models), where a business or business model is linked to a specific group of classes of goods, products, and services combined with a certain type of process, people, and technology.

A simple restaurant often has three businesses with different business models: In-House Dining, Takeaway / Delivery, and Catering. These three businesses target different branches and markets, have their own costs and revenue models and processes, and require different types of people to work.

Example The Smart and Green Enterprise

A new type of enterprise is emerging, called a Smart and Green enterprise. In these enterprises, any solution or service that can be made smart and green is made smart and green. We now see, for instance, that many municipalities and cities are switching to green solutions for their waste collection. They are much more nature-friendly.

Many governments are banning single-use plastics, causing businesses and people to adjust.

CTI concept

Dragon1 takes an entirely new approach to IT because Dragon1 regards the integral business IT solution as an architectural structure. By examining IT abstractly and analytically, it can be determined that IT enables an enterprise to inform, communicate, collaborate, and conduct transactions. Infrastructures are used to provide the necessary resources, and as such, IT becomes CTI.

It is normalized today to speak of information facilities and state that these are supported or enabled by IT infrastructure. CTID enables the architect to design communication, collaboration, information, and autonomous decision services and resources separately and integrate them. CTI enables the architect to design and integrate communication, collaboration, and information resources separately.

Also, Dragon1 recognizes that an enterprise operates common facilities at all levels and has generic, specific, packaged, and non-packaged facilities. By offering architects these degrees of freedom in facilities and infrastructure, they become less restricted in creating an architectural design.

When a user has no or only partial control over facilities, we speak of infrastructural facilities. Infrastructure covers the total of immobile facilities present. For instance, an ATM is an infrastructural facility; however, a mobile hotdog stand is not, although it is a facility of sorts.