Another article from my reading today - the case for Enterprise Architects from CIO Mag. Some points that really resonate with me:
- A CIO makes better use of an enterprise architect by having him or her focus on the technical viability of product solutions while determining their economic value to the business.
- There are so many vendors pulling and tugging on IT organizations. EAs have to be a shield for that,- A voice of reason.
- That person [EA] also has to gain the confidence of the senior leadership team. Execs must believe that the enterprise architect comprehends how the company works, where it wants to go and how technology helps or hinders. Then effective working relationships can bloom.
All of these points require senior management to have faith and trust in Enterprise Architects. It also requires that EAs have the opportunity to be involved in the planning of the business and any associated strategy exercises. This builds first hand knowledge and understanding of the issues facing senior management. The EA role is only as effective as the environment that supports and nutures his or her understanding of the wider business picture.
Another fascinating paragrpah is around moving temporarily (or crossing over) EAs into design roles (i.e. Solution Architect roles):
"In 2006, Grainger went live with a companywide SAP project-20 SAP modules and 30 additional applications that would touch 425 locations. To help guard against what could go wrong in a big-bang cutover, Ferrarell took his team of about 20 enterprise architects off their regular jobs and assigned them to design and integration roles on the SAP project. The SAP implementation was such an all-encompassing program that it made sense to re-purpose the enterprise architects into key roles in the project. Their broad business and technical knowledge made them very valuable team members, says Ferrarell. Grainger's senior business-side managers knew these architects and their business savvy firsthand, he explains. The trust was there, which helped get IT the intense cooperation needed during and after the complicated launch. Their architects played a significant role, not only in shaping the need for completion of the ERP project, but in ensuring its design would enable their business requirements. The SAP project succeeded, Ferrarell says, in part due to the institutional knowledge and business-IT translation skills the EAs brought to it."
It's my fundamental belief (in particular in a IT marketplace like New Zealand where resources are always scare) that having an EA getting involved in design on critical projects is extremely important. It brings a broader approach to an IT implementation that might otherwise be missed on a critical project breaking new ground.
I think the following section in the article sums it up about what an EA needs to do:
"An enterprise architect has to guard against getting too far removed to the management echelons and losing touch-and influence-with the technologists who design and code systems, Plant says. In other words, as much as an architect must build relationships with those outside IT, he also must maintain good relations with those inside IT who can make business plans into technology realities"
And don't underestimate the ability for an EA to execute:
'"Without the ability to execute, architects are going to constantly struggle with justifying their existence."
In my view to sum this all up - don't put EAs in a corner and get them to write strategies independent of technology and real business knowledge - use them for and develop their broad organisational knowledge and broad technical understanding. This convergence of knowledge is how you nuture, grow and get great results out of a Enterprise Architect.