Paul Ayers, Enterprise Architect, Oracle
The concept of Enterprise Architecture (EA) is a sound one. Having a framework and skillsets, which can assist with informing technology decisions, reduce complexity, duplication and technical debt while ensuring an alignment to business strategy-it is an attractive lure. In most cases, EA teams emerged from IT divisions to provide technology leadership and assist in setting the strategic direction for an organisation’s technology investments. They are (or should be) the keeper, and reiterate the technology vision. However, in recent times these groups seem to have fallen out of favor. Do they have a future?
It is the Program/Project management area where many organisations are spending their improvement dollars. This is because this area usually wears the brunt of project failures. However, this also takes the attention away from other capabilities like EA. The EA teams are being downsized and/or staffed with less experienced staff (as a cost reduction exercise). The EA groups are also typically painted with the IT brush therefore struggles to gain any credibility with business stakeholders.
The focus of EA groups has also changed over the years. It has swung around from trying to do everything from documenting the current IT estates to developing technology roadmaps and target state architectures, from solution design to developing white papers on the latest technology trends. Most have also tried implementing some sort of EA framework so they can get others to understand what they actually do but this usually ends with mixed results. Most of these EA frameworks are more academic than practical so they are becoming extraneous in today’s fast moving business world.
With the technology landscape changing quickly, business areas are getting impatient for change. With limited resources to undertake the work, EA groups are struggling to meet expectations. Indeed their relevance is being questioned in some circles.
With The Technology Landscape Changing Quickly, Business Areas Are Getting Impatient For Change
These groups haven’t helped themselves either by producing artifacts, patterns and new processes that are less than useful for projects to consume. In other words, EA groups have failed to understand their customer needs.
Lacking creditability, what is starting to happen in a number of organizations is that projects are by passing EA and implementing technologies that are further complicating the already complicated IT eco-system and steadily adding to the current technical debt. It might only seem like a small thing on the surface, a project making a tactical decision to get the development team to build a required feature rather than leveraging an existing function or buying something from the marketplace, which is pre-built. The usual argument you hear from the project is that if they have to buy something new it will put pressure of the project timeline due to the procurement overheads. The bottom line is that it’s easier to task a developer to quickly whip something up. However, if the project gets its way, the end result is more duplication and/or bespoke code, which needs to be managed, updated, and maintained for the life of the system.
Just like the investment in Project/ Program management offices, an EA practice needs investment in skilled (not in just technical but people skills as well), motivated, pragmatic, and business focused staff. It also needs agreed measures to demonstrate that the investment in the group is making a difference. These could be around a reduction in technical debt, or the number of reused corporate assets in solutions designs, or how many systems were designed using existing patterns. A measure of business improvement also needs to be included as EA should be more holistic than just IT.
Investment in EA governance needs focus and is required to be incorporated in the Program/ Project management processes to ensure that the technical solutions abide by the architectural principles defined and approved by the EA Board. An active EA Board is critical in quality outcomes and should work hand-in-glove with the Program and Project methodologies and governance models. An Enterprise Architect should be embedded in Project teams for the life of the project and your senior EA should be a standing member of the Program Board. Most importantly an Enterprise Architect needs the authority to make judgment calls in an environment that is well supported by an appropriate organizational governance model.
EA can be a key enabler for any organization as long as it has a clear focus of what problem(s) they are trying to solve–they can’t solve world peace! As each organization has a slightly different set of problems and levels of maturity, it’s not possible to recommend a single approach for your situation. This is why it is so important to list and prioritise your problems so that you can focus your precious resources. Undertaking such an exercise can be challenging as there can be so many issues that need attention but with some professional facilitation some good results can be achieved.
Established in 1977 and headquartered in Redwood Shores, U.S., Oracle offers an integrated stack of business hardware and software systems and services to more than 380,000 customers in over 145 countries.
