EA purpose

There was a challenge to describe the EA purpose in 160 chars on Linkedin EA Network discussion group. There were more than 300 responses. It looks like the challenge was taken as to define the purpose of EA for the first time, since seldom were posted definitions coming from well known fora or from Zachman, for instance, who is well known for his discourses on EA justification. 

What pushed us to create new definitions? Isn't this originality coming from the lack of agreed standards? 

Obviously, there is division in our ranks on what we do and for what purpose. As such, do we perform the same job? Having seen this, what would be the expectations of our customers? Could customers expect consistent results? 

No wonder then we have so many Enterprise Architects and so few Enterprise Architectures.

An analysis of such responses should conclude, not on the purpose of EA, but rather on the state of our profession, surviving without an agreed EA body of knowledge that is definition, scope, method, framework... What governance do we need to agree on these basic assumptions? 

Even architects' certification would not help without a reference body of knowledge because there is no basis to assess a professional against. 

But in the end the answer is simple. EA means architecture (after all it's in the name), i.e. a blueprint. As such,each and every stakeholder uses the blueprints for own purpose: discover a system, improve a process, map strategy... There is no single purpose. 

Or, were I to classify them, I would say EA enables Enterprise streamlining, alignment, agility and strategic planning.

...

I agree that EA is about provding data (ideally as blueprints, the views of the current and future Enterprise and the transformation roadmap). 

But I don't think the EA architect has to interpret the data for business. 

In fact each and every stakeholder would use the architecture in a different way, for a different purpose. The EArchitect has to model and document the views that reveal the business information so that stakeholders can interpret it, at leisure. The EArchitect does not have the knowledge to interpret it. And there are too many stakeholders and too much data. The EArchitect would become a bottleneck. 

The EArchitect should be work close to business and management to collect the requirements about what EA is about document. Once this done, the EA is for stakeholders' use. 

I believe though, that it is an aspiration of many EA architects to become trusted business advisers.

...