EA FAQ‎ > ‎

EA discipline

What is EA all about in these times and era? Good question after so many years of "doing" EA. But people seem to ask this question again. Gartner appears to redefine it's approach to revive interest in EA. Forrester stresses the business architecture revolution in EA. 
For sure, there is more emphasis on business architecture. With the advent of the cloud, lots of businesses will move some IT into the cloud. If all the technology is moved into the cloud there would not be much point for an EA defined as an IT architecture. Nobody clearly defines business architecture though. 
The EA currently addresses only IT and not very well since there is hardly a mapping to business (no business architecture!). 

Definitely the EA concept promises a lot. But, as it is, the EA hasn't returned the touted benefits to the business or, for that matter, even an architectural blueprint as the name implies. 
EA comes, typically, with a few applications, servers and networks diagrams in a wide variety of forms and shapes. No navigation, little idea of what is missing, usually the artefacts satisfying just a few owners in IT. Few people use them. The main occupation of the EA Architects is to review solution architectures, to provide soon to be forgotten technology standards, lead architecture governance boards to make decisions on applications and technology with very little guidance from the existing EA, if any. 
Currently, the EA work fails to deliver because is done in isolation by IT for IT without the business insight in how the firm works. 

There are more books, more conferences, more dialogs, papers... But EA aspects are taken and analysed in isolation. The EA is about the whole. 
Everybody seems to be waiting for a new direction, a wagon to jump on to make the EA really deliver. 

So what do I suggest? A collective EA effort sponsored from the top. 
Let the experts do the work at each layer: the business people (6 Sigma for instance) do the business process map work. Let them own the process improvement as they currently do, but integrate their work in the EA effort. 
Let the IT people do what they call today EA. But link to the process work for mapping. 
Let then the business improvement and management teams do the organization design work, redefine the chart in alignment to the business process and EA technology responsibilities. 
There is the EA documentation work belonging to the EA architects and involved parties. Then there is the EA transformation work, according to strategy, that does not belong to the EA architect alone but to the top management and business teams. 

The EA team must chiefly coordinate the process improvement and documentation (Lean/Six Sigma, BPM..., TQM) effort, the organization alignment work and, not least, the technology blueprint design, mapped to the business view. 

The EA lead team needs to spell the work streams which should be lead by EA/domain architects, process and project managers and the organization design team. 
Let us work together: the EA architect, the business experts, the business analyst, the organization design team, the management and business consultant and the top management sponsors. As such, independent efforts like BPM, Lean Sigma, organization design, IT architecture, strategy mapping come together under a single EA umbrella effort and Enterprise project portfolio. 

The EA architect was compared with a CEO. The EA job descriptions, mentioning strategy, roadmaps, blueprints, business models surely look very impressive. In practice an EA architect has no budget and no authority to implement anything. He is perched on a low branch in the hierarchy. How could one fulfil the expectations then? 
The EA chief architect role needs to be higher to achieve anything, positioned to be able to have influence in process, organization design, strategy mapping, resourcing and budgeting decisions.