Easy Enterprise Architecture

This post reflects a personal opinion that will be elaborated upon in following posts.

The word “easy” and the words “enterprise architecture” seem incongruous in the same sentence, an oxymoron if you like. Reading about enterprise architecture and talking to enterprise architecture practitioners, and consultants, often leaves us with an unease that such an enterprise architecture implementation is complex beyond expectation and will involve a massive learning curve, together with (as yet unbudgeted for) massive investment, all on top of an extended time span.

This may be true, but before we indulge in worst case scenarios, there is a light at the end of the tunnel (and it’s not a train). Enterprise architecture is not something that needs to be started from a zero basis, but large parts of it may already exist as part of previous projects executed in the organization. Iyer and Gottlieb (2004) argue that enterprise architecture emerges out of the implementation of individual projects.

The implication is then that parts of enterprise architecture that already exist should be investigated and a picture, very much like an incomplete puzzle, should be built.

What should we be looking for?

Enterprise Architectures contains components of strategy, business architecture, information architecture, application architecture, data architecture, and hardware and communications architecture (Cardwell, 2008).

Traditionally, information architecture, application architecture, data architecture and infrastructure architecture is well developed as project and operational artifacts. This may also extend to business architecture from the point of view of business optimization, quality certification and legal and regulatory requirements. Strategy as the primary artifact of the enterprise board and executive management should be documented in various manners.

What about the skills?

Another consideration is the skills required for enterprise architecture development. Existing project artifacts were delivered in the enterprise with existing skills. The focus should be on identifying those skills, evaluating its usefulness and then incorporating it in broad skills set that may be used for the later development of formalised enterprise architecture.

In conclusion, it is the opinion of this author that many artifacts and skills which make up enterprise architecture is present within the enterprise and should be leveraged in a coordination of enterprise architecture, rather than developing enterprise architecture from a zero base.

References

Cardwell G. (2008), The influence of Enterprise Architecture and process hierarchies on company success, Total Quality Management, 19(1-2):47-55

Iyer B., Gottlieb R. (2004), The Four Domain Architecture: An approach to support enterprise architecture design, IBM Systems Journal, 43(3):587-597