Enterprise architect, solution architect, whats the difference?

I see most architecture practices have progression marked from solution Architect to enterprise architect.So what does it take to make this progression?Is it, for example, that once you have been solution architect for 'n' projects you are qualified to become enterprise architect? or is it if you have been solution architect for 'n' types of project hence you can become an enterprise architect. Or is it analogus to a caterpiller becoming a butterfly? Is there a moment of Zen, when a solution architect becomes enterprise architect? Can an enterprise architect descend to become a solution architect? Is it really a descent?
Let me attempt to answer these questions per my understanding.To me a solution architect provides a framework so that a sound solution can be designed and implemented. Since a solution typically spans multiple orgnisational entities within enterprise, the framework thus established, in a sense is valid for entire enterprise. So what value does an enterprise architect add, over and above this? An enterprise architect has to set up such a framework for entire enterprise (and not restricted to some entities within it). A solution architect has some freedom in setting a framework for his solution, based on overarching framework for enterprise. He can override enterprise wide framework, if his solution so demands, after following governance protocol. A solution architect can extend the framework and make it more granular. That is, enterprise wide framework will be more coarse grained, whereas solution level framework will be more fine grained. This solution level framework will have some reusable parts, which can be envisaged in any solution. Those should be moved to enterprise framework. Lifecycle changes happen in a solution level framework till the solution gets deployed and then the framework is frozen. Whereas an enterprise architect has to make sure his frameowrk is deployed rightly across various solutions and govern the changes or diversions from it. He also has to keep evolving organisation wide framework, all the time.
So from an Object Oriented viewpoint a Solution architect is a base class (appears counter-intuitive). An enterprise architect is a derived class. An instance of enterprise architect is also an instance of solution architect, but an instance of solution architect is not an instance of enterprise architect. Once a soluition architect develops the ability to genralize and abstract architecture concepts, he can progress to become an enterprise architect.

Requirements management is crucial

It is pertinent to ask how other disciplines of engineering are able to build systems with guarantees, whereas software engineering cannot guarantee anything. Is it due to 'softness' of software or are there fundamental differences?

One fundamental difference between business systems and the systems built by other engineering disciplines is that the later deals with physical world, which is well understood. There are precise models of systems, which scale up. We in software engineering equate models with pictures. But what I mean is that they have higher level of abstractions to express the detail. Be it a set of partial differential equations, or a complex formula of that kind. The key is that these are models rather than enumeration. And system requirements can be expressed in terms of these models and measures used in these models.

E.g. one can specify behaviour of physical system using properties such as Pressure, Temperature. Then one can specify requirements in those terms. The implementer knows how components behave for given input and can construct an implementation meeting the requirements. Implementer can find out what will be the value of Temperature given Pressure. So he can decide how to set pressure so as to achieve the expected temperature.

I think equivalent measures for business systems are Data and Process. Unfortunately we have no clue how they behave in isolation or what is their interrelationship. There are no partial differential equations describing behaviour of data and process. So we have to specify the requirements as enumeration over data and process.
Imagine if an engineer had to specify what will be Temperature for every value of Pressure, and then describing what Pressure range he wants the system to operate in with what max. temperature. Yet, this is what we do as requirement specification in software engineering.

And if your enumeration is not complete, you have a flaw in specification. And nobody can build correct working system, with a flawed specification. Of course we still have a problem of converting a specification to implementation, without introducing any error! The MDA approach is trying to address that. Also manual way of converting requirements into implementation is well understood now. It is a problem, but a better understood one.

Yet there are some systems built using software engineering, especially aviation related or embedded systems (like one found in washing machines), where a more formal approach is adopted. The requirements are specified formally and then validated before implementation is built. It is possible because either the requirement can be specified, as in other branches of engineering, using scalable models or the enumeration is tiny, hence without problem of scalability.

So for business information systems there are following problems,

1. Abilities to represent the abstract specification (the model) aren't mature
2. Completeness and correctness of such a model is difficult to establish
3. Scalability of such a model (model becomes bigger and more complex than the system, for large systems)
4. Converting such models into implementations (if you can address all of above, then you can use MDA approach to achieve implementation or do it manually)
   

These are not easy issues to handle, especially item 2 and 3 in the list above.

What is this got to do with Enterprise Architecture? Well, as an Enterprise Architect one is helping build information systems for enterprise while trying to reduce TCO, protect investment and avoid obsolescence. All the modern approaches, which aim to simplify the building and maintaining of information systems, (e.g. ESB, SOA) have a need for requirement specifications, with its own representation mechanisms (e.g. BPMN). If one is not aware of these fundamental issues in systems requirement specifications, then these implementations are not going to succeed. So while one can delegate the implementation part to vendor tools and project teams, EA must take charge of building, managing and governing these requirement specifications as top priority item. This is also a key to better business IT alignment.

Services as contract

Recently we had a visit from Bertrand Meyer (Eiffel fame). He mentioned how Eiffel langugae helps make contract explicit between user and supplier. He also elaborated in what all different ways the contract definition can be used. (One of the interesting uses he showed was that of 'push button' testing). When I asked him that how does the language discover the contradictions in contract specification, he said "It does not". Which was kind of disappointing, a wrong contract specification, howevere faithfully implemented by the implementor, is no good.

This incidentally is the point I made in one of my earlier posts. Not only, one must make the contract explicit, as most SOA proponents are proposing, but also we must have ability to discover contradictions in the contract specification. We must have ability to see, if multiple contracts can co-exist and satisfy some common properties. It is not easy. However this is an important aspect of contract specification and must be addressed. The service definition should define how the compatibility would be established between various services (which essentially are contracts) and governance must ensure that this continues to be the case. Such defintion time checks, will help prevent costly budget and time overruns not to mention prevention of service proliferation and governance nightmare.

Enterprise architects must show leadership

I have observed that in most organisation Enterprise Architect (EA) community is viewed as 'ivory tower idealogue' and creating nothing but 'PPTware'. In entire IT orgnisation no other community is derided more than Enterprise Architect community (may be project management community can compete with EA community).

The business and IT leaders sanction Enterprise Architecture organisation and budgets, partly because all analysts point to such a need. But I am not sure how convinced they are about necessity of Enterprise Architecture. The solution implementor(for lack of better word) community always wants to be left alone and do not want to be dictated to, by Enterprise Architect community.

This is not an ideal situation to be in for Enterprise Architect community, where neither your superior nor your sub-ordinates have any faith in you. Is it because Enterprise Architect community always devises these nice 'end games' or 'to be state' or what have you, but fails to lead the IT organisation to that utopia? The probelm arises when in order to reach the end-state, what needs to be done in near future is not spelt out clearly. How does one trade-off the pressures of business changes, changing technology, organisational culture and still work towards the desired end state? Enterprise Architect community must provide practical answers to address these trade-offs without losing site of end state. This is very difficult.

Just to site an example: In an IT organisation, I was working with, all funding was tied to business benefits. Now some of the infrastructural projects, that needed to be carried out in order to reach a desiraable end state, did not have any chance to be implemented. Because cost benfit analysis will stack up heavily against such project. One cannot blame business for having such stringent benefit centric approach, because in the past business had burnt millions without IT producing a single usable artifact. An Enterprise Architect needs to tread thru such situations, and provide viable and practical approaches.

This is, in essence, challenge to Enterprise Architect community and when Enterprise Architect community successfully tackle these situations, it will gain the respect of overall IT community. So the job does not end with defining Enterprise Architecture, but it is a mere start. The real challenges are in governance and deployment of Enterprise Architecture and showing necessary leadership.