Architecture part II

Back to the digital world
In part I of this series we compared digital architecture with architecture of the physical world and mentioned enterprise architecture, reference architecture and project start architecture. In this installment ‘Architecture part II, back to the digital world’ I will explain something about Enterprise Architecture and projects & change.
In part III I will discuss Reference Architecture and Project Start Architecture. Of course there are more architecture types. I will discuss these later.

Enterprise architecture (EA)
In a lot of organizations architectures are made on the basis of the corporate strategy and on strategic goals and objectives. It wouldn’t be right otherwise, right? These architectures are ‘high level’ and have been established to promote the communication between business and IT. The viewpoints discussed and the models drawn in the context of an EA address a range of issues. It addresses problems that are current as well as potential. Thus, the main concern of an EA is the enterprise -wide identification, specification, and prioritization of business needs.
Now and in future.
Only this kind of architectures we can, in my view, call enterprise architecture. No invariable blueprint with a lot of details but a benchmark, as is the mission or vision of the company. It includes much more than a single proposed solution and may even result in multiple, simultaneous implementations. An EA is a more holistic view that unites business and technology needs based on a strategic enterprise vision.

It seems obvious that such an enterprise architecture is laid down as a kind of law by the governors of a company, such as the CEO, the CIO or a Board of Directors. You must consider EA as the IT strategic plan of the enterprise. It serves to give consistency and identifies dependencies. It outlines which direction must be followed and gives direction to the desired consistency of services, business processes, organization development, use of data in the information system, applications, and technical infrastructure in the organization and contains explanatory pictures and the most elementary construction rules.

EA and change
EA concepts have been around for a while. In due of accelerated environmental changes in organizations of all sizes across most industries business agility and, in particular, the ability of the technology infrastructure to respond to change in a timely manner have reached critical importance. That’s why the enterprise architecture discipline has gained such momentum.
Another factor contributing to a growing appreciation for the enterprise architecture discipline has been the more stringent regulatory climate, which is driving organizations not only to improve their accountability and reporting practices, but also to make compliance organic to every business process.
In response to this sharper focus on EA principles, enterprise architecture ‘paradigms’ have emerged, such as TOGAF ADM (the open group architecture framework, architecture development method) and Zachman’s framework , IFEAD (The Institute for Enterprise Architecture Development) and NORA (Nederlandse Overheid Referentie Architectuur) However, they differ substantially. E.g. because Zachman is a framework, TOGAF a method and NORA focuses on SOA and is meant for Dutch governmental organizations, etc.

EA to guide change
An enterprise architecture is subjected to change as the mission and vision of the organization and business requirements becomes more clearer and the companies environment is changing too.
When big changes are to be realized we tend to cut them in to smaller multiple projects we call ‘change programs’. The enterprise architecture can be used to guide these changes.

The translated desired company characteristics guide the need of projects and change programs and gives implications of these changes. Thus it is a means for architects, information managers, business consultants, design teams, designers and EDP-auditors to be able play their role, in projects or change programs, well.

With enterprise architecture you can:
 Recommend the management and program management about choices. (some models translated in more communicable pictures and drawings.
 Make frameworks to outline architectures at the start up of projects
 Proactively (give direction, train) guide designers
 Review of products (reactively) from change programs on content and consistency.
 Give business consultant, design teams and individual designers a ’stocked backpack’ so that they are able to follow direction and make the correct choices.
 Use it as reference by the internal Audit Department and external EDP-auditors.

The success of the concept of ‘changing under architecture’, through guidance from EA not only depends on a common, coherent picture of where an organization wants to be in future, but at least as much of the way the organization wants to achieve this and the willingness to adapt to change if necessary.

This asks for an intensive cooperation between architects, business people, the IT department and to a process in which it is clear & has been decisively agreed upon, how further interpretation, adaptations and deviations on architecture are realized.

When architecture is of that type, it really offers an ‘instrument’ to reduce the risk on loss of substantial consistency and give means to manage consistency. Guaranteeing consistency can, on the one hand, be realized by following construction principles of the company and on the other hand, by getting integrated insight in the structure of the company, by applying these principles.
This gives a grip on design, development, implementation and management of the renewed part of the organization.

Back to the physical world?
The function of an enterprise architect can be compared to that of a city planner. In contrast, the function of a ‘building’ architect is more readily associated with the IT architect role. The enterprise architect role often emphasizes the inductive skills of a detective over the deductive skills of a builder. However, the high-level perspective of the enterprise architect does not mean that this role is disengaged from the user community. On the contrary, an enterprise architect must be involved in helping customers understand their real needs (as opposed to wants) and to work with them throughout the implementation of a solution.

At the same time, an enterprise architect should be able to view his or her domain at a level of abstraction that prevents direct involvement in the practical aspects of implementations.
An enterprise architect should be able to understand the business problem and the business domain and explain it to the technical people and to be able to understand the technology domains and explain the technical possibilities to business people.

It is important that an enterprise architect plays a pivotal role in architecture governance, a function that is often either shared between assorted business and technical roles or, even worse, simply ignored. Architecture governance is the glue that provides both a context and a framework for all enterprise and project architecture activities.