Enterprise Architecture (EA) is a term that has been used loosely and redefined to meet specific needs of various IT organizations, movements (such as Java and Open Source), and individuals needs.
Recently I saw a debate on the usefulness of EA being debated in a forum I belong and subscribe to. The business executive was frustrated with trying to understand the principles of EA as it has changed in metamorphic ways to suit the needs of specific groups.
I shared my opinion below with this group – each consisting of readers who hold their own perspective, and each with their own turf in business and IT to defend. I will be interested to see the feedback – but I will put my thickest skin on when doing so.
EA – in my humble perspective – is the bridge between the business community and the IT community within an organization. It holds an equal obligation to the business areas of the organization it serves and the IT strategies in place and their future direction.
Some may confuse the role of CIO with that of the highest level of EA in the organization, but most often, the CIO is protective of their IT holdings which degrade their objectivity.
Quite common are environments where the business community must request a service or function be designed or modified. The result of such environments are simply piles of IT solutions with no clear sight on long term IT objectives.
Such environments are frequently plagued by systems that quickly reach the end of their lifespan before fully optimized or integrated with surrounding components to reach their full potential.
On the other end of the spectrum is the IT department that dictates the services to be made available to the business community it serves. The outcomes of such environments usually include very integrated systems that provide services that may or may not be used by the business. These environments are built on state of the art technology not yet mature enough to be fully utilized.
In the middle of that spectrum – a fairly broad band in the middle – lies the environment governed by the principles of EA. EA is an independent objective function. The EA may be the role of a sole individual (a very special individual) or more commonly in the form of a committee – each equal and representing different aspects of the business community and the IT department.
EA balances the immediate and long term objectives of the business to insure both sets of needs are met – while the technologies that service those needs are responsibly deduced to insure the technologies are feasible in terms of security, affordability, scalability, risk, and longevity while at the same time to insure the best chance for ROI to be achieved. Extensive modeling from both business and IT perspectives flash out such strategies giving optimum view to the full 360 degrees of the impact on organization.
An IT environment governed by AE principles may very well still have a core backbone of key independent COBOL batch processes that perform the organizations basic processes while extending the use of the processed data with newer technologies as they are adopted in standardized means to fill specific roles.
There is no one definition for EA – each organization who employs EA principles determines that definition clearly and concisely.
In short, true EA – much like a Zen-like approach to life itself – in an ideal to strive towards, but that few truly ever achieve. But by adopting the EA principles and religiously applying them will only strengthen the organization it serves and governs.
