(first entry, september 2008)
In part I we compared digital architecture with architecture of the
physical world and mentioned enterprise architecture, reference architecture
and project start architecture. In this blog I will explain something about
Enterprise Architecture and projects & change.
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
addresses 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 purposed 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, coherence 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 it 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 is why the enterprise architecture discipline has gained such momentum.
EA and regulations
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) IAF, etc. 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 to play their role, in projects or change programs, well.
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.
Change & success
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.
An instrument for change?
architecture is of that type, it really offers an ‘instrument’ to reduce the
risk on loss of substantial consistency & coherence and give means to
manage these. 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 into the structure of the company, by applying these
principles. Coherence is gained by continuously showing the BIG picture and the
relationship between the parts.
This gives a grip on design, development, implementation and management of the renewed part of the organization.
Back to the digital
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.
Level of abstraction
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
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.