EA Architects

What do Enterprise Architects do? 

That depends. A good number of Enterprise Architects (EAs) appear to come through the professional promotion ladder process which ends up at the top of this value chain: the Enterprise Architect. They are veterans, they know people and people knows them, they give advice and are knowledgeable about the company history, culture and motivations behind every technology in existence. They are often consulted by management and occupy a position of respect since some are legends for services rendered. 

Do they really do Enterprise Architecture? They mostly don't. They do check consistency of designs between projects and against their own experience but they do not have a reference Enterprise Architecture to validate results against. 

But let's move on. 

The next type is the Enterprise Architecture Integration architect; it is an important role since most applications are hard to interconnect even today. They are chosen from the SOA ranks, as the middle name for SOA is integration for most adopters. They use middleware, mostly based on ESBs, JAVA/JMS, MQ Series and/or Web Services. They are often found in Enterprise Architect jobs. Sometimes called SOA Architects. Do they do Enterprise Architecture? They do the EA integration bit. 

Then the well known Enterprise (JAVA) Architects called so because of the Enterprise Java Edition so naming. The technology is said to be Enterprise wide. There are some called Enterprise Solution Architects probably because they naturally work in solution delivery projects. They do a lot of patching work in their platform of preference to keep the applications running. This is not really Enterprise Architecture work. 

There is also the IT strategy role where mostly the Enterprise Architect works on the IT technology roadmap which is associated to Enterprise Architecture and Strategic Planning. If not based on an Enterprise Architecture this role will deliver best effort silo-ed outcomes.

The Enterprise Architects are often classified in: Applications and Infrastructure architects to enable work division and specialization. They often end up doing inventories of technologies and applications. They are usually present in most meetings since they are supposed to cover the whole Enterprise. 

Sometimes the Enterprise Data Architect role is also created when the Enterprise has trouble with managing its customer data or extracting reliable intelligence from available sources, which is quite often, simply because information is duplicated in a few applications. 

Typically, applications, technology and data architectures have little in a common: separate diagrams with different entities, drawn by different architects without a common picture. In truth, the existing EA frameworks recommend you do the usual business, information, applications and technology layers and leave you at that. 

Is this a problem? No analysis transcends from one view to another, changes are not propagated, impacts are not resolved and IT is not aligned to business or strategy. Hence it is a problem. 

...

What Enterprise Architects actually do? It did not surprise me to discover that Enterprise Architects don't do much Enterprise or business architecture work for that matter. What is business architecture anyway, a few business process diagrams? It is true nevertheless that Enterprise Architects tend to be experienced people who may engage and solve most IT situations, in a flexible and clever manner. 

What an Enterprise Architect should do though? 

The job starts with putting together an EA business case to justify the EA development once for all, then sell the EA to business and management to get sponsorship and resources. Afterwards, the EA framework selection, customization or creative design since most frameworks are not going further than general patterns like matrices, layered pyramids, cubes, process and best practices etc. This is a critical success factor for the rest of the EA development! 

The architect establishes the design principles, the process, breaks down the EA work into workstreams and organizes the teams to discover and document the current Enterprise state and blueprint. The Enterprise Architect validates other Enterprise developments from an EA point of view: all solutions architecture design have to comply to EA principles and conventions reuse the same components and link to other artifacts. Also, the ERP, SCM, CRM, MDM, Portal and business specific applications, suites and activities have to be properly documented at the process and technology layers. 

As the EA becomes the knowledge DB of the Enterprise, the content has to be organized early in an EA taxonomy and exposed on the Intranet. The EA architect leads this effort. 

Then the architect looks at the Business and IT Strategies aligns them to the Enterprise Map, determines the future state of the EA and establishes technology standards, guidelines and roadmaps. Then the EA architect specifies the EA compliance criteria and process controls, evaluates EA maturity and not least, coordinates the entire EA development work. Most Enterprise Architects don't do that. (They do though, validate most IT developments against their own professional experience which is good but leads to variable and debatable outcomes.) 

Well, there is an explanation for that. The "body of EA knowledge" is scarce, fragmented, contributed by practitioners from experience rather than academia. There is a reason for that too. EA crosses the boundaries between the theory and practice of business (existing since the dawn of time) and IT (still young and playful, celebrating about half a century of existence)... disciplines that until now have been treated in utter separation. The Business side concocts a system specification, the business analyst translates it and the IT implements it. But business and IT have different cultures, objectives, vocabularies and require very different skills. Hence, the division between Business and IT does well without an Enterprise Architecture to align governance, goals, processes, communication language... 

...

How does one select an Enterprise Architect (EAs)? So many around these days. No wonder because the title and pay are attractive. Since there are few distinctive qualifications or selection criteria for an Enterprise Architect, how do you recognize an Enterprise Architect? Is it intuition? Is it the good old boys network? 

Most EAs have studied TOGAF, Zachman, FEA and quickly gave up on DoDAF. These appear to be the universal requirements for an Enterprise Architect. Nothing earth shuttering though, no mathematics, almost marketing like material. 

Zachman it's quite straightforward to read and understand by all. It is common sense. Long before that, Rudyard Kipling's poem "Elephant's child" from "Just so stories" beautifully suggested, an every day life discovery process based on the "w" questions: 

"I keep six honest serving-men 

(They taught me all I knew); 

Their names are What and Why and When 

And How and Where and Who...." 

(Zachman 2 is coming, I hear, surely adding some substance to the Mendeleev's elements table, the framework was likened to) All of us browsed TOGAF (hard to go through otherwise due to its richness). 

FEA is a bit of a read, in fact there are quite a number of documents, but what remains in one's mind is the simple framework (consisting of performance,... business, services, technology reference layers) which is not quite rocket science. But if you read specific agency frameworks you discover they differ in many ways, fact that may baffle you a bit. 

DODAF, not bad at all, formalizing descriptions in diagrams types connected by a metamodel, complementing FEA models in many ways, has its own vocabulary that departs too much from the EA accepted modeling. Hence it is hardly usable except in defense. 

As such, it is not too hard to tick the methodology boxes for an Enterprise Architecture job: Zachman, TOGAF, FEA and other (IAF, EAP, E2AF...). But unfortunately this is not too distinctive, in fact it provides no differentiation since most architects can claim this. 

That is why the Enterprise Architect's curriculum must be backed by a long IT experience and references. Good social skills proving that he/she is articulate as well to communicate with stakeholders and "C" level management (sounds catchy!) is a must, they say. In any case, you must keep your nerve explaining to everybody again and again what it is, why, how you are going to do it. As soon as you leave, people start asking anew, what was that for? 

Counting these criteria, is it possible to narrow down the candidates to a short list?

...

Currently, Zachman, TOGAF and the soft skills tick boxes decimate the number of candidates; but is that enough? By the way, has anyone been asked at an EA interview, what are Zachman or TOGAF about? I find it difficult to find questions with answers relevant to the framework since knowledge about, is either straightforward or common to other disciplines. 

Typically, technology criteria are further employed for selection: experience with Java frameworks, .Net platforms... although software programming is not a basic requirement, strictly speaking, for an Enterprise Architect, but experience of it, yes. An Enterprise Java architect knows more about programming in JEE than the development of an Enterprise Architecture, which is natural. The real need for an Enterprise Java Architect is in Enterprise Applications Integration and patching. 

You will often find the Enterprise Solution Architect role as well, where the chosen one ought to do whatever work comes that way, Enterprise wide, from Java to TOGAF. This is quite an one man band requirement but would attract a Solution rather than an Enterprise Architect. A solution architect is someone who, starting from business requirements, selects an IT application most suitable from a functional viewpoint and for integration in the existing IT landscape. The role is less hands on than the Enterprise Java Architect, working more closely with the business. 

Then, many demand experience in the specific business domain such as financial, insurance... The experience might help speed the process, but unfortunately they may eliminate the real Architects. 

Anyway, as in the previous case, this is not really a requirement for for an Enterprise Architect which should work with and mobilize the business to design the specific architecture. An Enterprise Architect would apply method and frameworks to your EA rather than attempting to substitute software designers and business people and their expertise; he would model any business, on any IT platform, following the same process, no matter what industry, beginning with products and stakeholders' interaction specification, continuing with the functional decomposition and process design and engineering and, not really ending with the architecture of the resources executing it, IT and people.

...

Until now, I neglected the architecture skill, the most important in fact in the selection process. What is an Architect? It is someone with a structured mind, who likes to discover and use patterns and is willing to do this tenuous job. The Architect digs to discover the essence, like a true IT intellectual, and feels the inner need to understand how parts fit into the whole. A craftsman and artist, since Enterprise Architecture is far from being a science right now. Usually, is experienced in more structured disciplines such as hardware and software design. The architect also struggled at some point with OO UML and distributed components technology, hopefully not too much CORBA. 

So ask what architecture is, what are the artefacts for an EA, how are they linked, what is a metamodel, how would the candidate design, implement and maintain an EA, what would be the work breakdown, what are the architecture principles or styles... 

Finally, you've got yourself an Enterprise Architect. But will you get an Enterprise Architecture? Probably not. This is a problem: all companies have Enterprise Architects but no Enterprise Architecture. Life goes on; the company survived without an EA for many years already. 

Anyhow once you have the Enterprise Architect in situ, the problem seems to disappear: the EA box is ticked and the peace of mind descends upon everyone, including management. No Enterprise Architecture though. But since few know what that is, a few diagrams of interconnected applications will quench the thirst for it. 

But remember what the Enterprise Architecture is: the documented structure and operation of your company. Hence EA is a necessary evil in this era of fast change, growing complexity and amount of information. The Enterprise Architect must be a dedicated and well rounded man that has to apply creatively the existing body of knowledge since the current state does not support well your endeavor to create your Enterprise Architecture.

...

Consultancies, do they have EA frameworks? Most of them yes, some variations of the "legacy" ones. They count a lot on the collective consultants' experience with plenty of former projects to serve as examples. Aggregation or consolidation of all work in a single framework is seldom performed though, to the best of my knowledge. 

Consultancies worry less with the selection of an EA consultant. There must be a hard working chap with a mortal desire to travel a lot, camp in hotels, hostels, managed apartments, dine in planes and trains, be mobile connected till late, live with an allowance of about 30-40$ a day but be able to impress customers with a no nonsense EA talk leaving few questions unanswered or providing the legacy answer "there is no silver bullet". More often than not, customers don't expect wonders anyway. In fact, in most cases consultants are more like "contractors", in that they do what the customer tells them rather than tell the customer what to do. 

For a consultancy, a typical framework - that changes and varies quite often - is based on the few known layers (business, information, applications, technology etc) conveniently surrounded by a few great Zachman style questions, such as Why, Who, When, Where.... Orthogonally one will always find a security slice. Some have Strategy on top to show how important it is. These frameworks look like triangles, two dimensional boxes, tables, cubes, pyramids that really give you the impression of Architectonic monuments and with it, the good warm feeling that we talk about architecture. 

When the EA exercise ends, the customer remains, with a diagram occupying a boardroom wall displaying and impressive myriad of connections and actors. At the top there always are the customer channels since the customer is king - that's marketing speak. There is a little bit for everyone but not enough to keep the interest long. Not quite touching the business issues or views. A bit hard to read, standing there and who's going' to maintain it? The consultant. One cannot print it since equipment like this is a rarity. 

Consultancies usually have other Enterprise wide assignments, not only Enterprise Architecture design. That saves the day. The consultant must be flexible and inventive. Must be self-reliant, confident, bendable, ductile, non-vertebrate, cool and an "accomplished communicator" so that he can inspire confidence and sales even to his own boss. Communications to level Cs if not higher is a must. 

The EA consultant is often compared to a body in a body shopping process, i.e. engaged in whatever work the customer desires over a while. The body may have a soul but that is not part of the contract. There is a striking similarity with the oldest trade in then world. a consultant, like Faust, would sell his soul for a viable framework.

...

I often wondered how does a recruiter recognize an Enterprise Architect. I concluded he/she does not. Too hard a job if the architects, those occupying EA positions or employers have different views of what EA is, its purpose and what they do. 

While I watched an EA purpose discussion (> 200 entries) on Linkedin, I realised that few quoted definitions from known sources. As most entries were different, I concluded that the EA body of knowledge is fragmented, not agreed upon. That is most likely because there are too many schools, definitions and frameworks. The intriguing thought, given the creativity of these responses, is that the architects themselves seem content with this state of art that gives them freedom to define as EA whatever they do. As a result, E architects most likely, do different jobs. The benficiaries of EA would never know what they get, in particular because, they don't know what to ask. 

There is a category of Enterprise wide IT Architects for domain like infrastructure, applications... They are are professionals able to see and draw a big picture, for a few functions of an Enterprise, in the domain there are in. They are not really Enterprise architects but they are called so when they are part of an EA team. 

EA is not about SW architecture either. SW architects, Enterprise Java Architects are in fact developers. 

IT solution architects design the block diagram of an application, its components and its context. 

IT Architects are not Enterprise Architects for the simple reason that they don't know and are not even interested in how the Enterprise works. They are often called E Architects, when having accumulate experience, they review all IT solution architectures in the Enterprise in order to make recommendation to reduce duplication, standardise etc but seldom having a common framework or EA blueprint as reference for decision making. 

In fact, there are too many Enterprise Architects and too few Enterprise Architectures. 

The confusion between EA architects and IT architects bothers because the "wrong architects" as Gartner calls them in "10 pitfalls...", are employed with results for firms and EA discipline we already know.

...

An Enterprise Architect, whose scope of work is the whole Enterprise rather than IT, should coordinate and integrate the BPM effort with the rest of EA workstreams since (1) BPM is part of the EA business architecture layer and (2) the BPM CoE is already responsible and best qualified to do it. 

Currently BPM/xSigma and EA developments are working in parallel, to my knowledge, because too frequently the EA is IT centric. 

More, a BPM effort in isolation may not lead to expected results because processes are often implemented in IT, take for instance ERPs, CRMs... 

Equally so, an IT EA devised in separation would lack the big picture of the business flows and aims. 

For this to happen the role of the Enterprise Architect should be elevated at the business management level, indeed. How do we ever achieve this? 

I would argue that EA should be logically at the level immediately above the organizational functions it coordinates (IT, business improvement, BPM...). But that depends on the scope of the EA in that specific organization. Ideally it would be reporting to the CEO for broadest scope and benefits. In practice it often reports to the Head of IT Architecture, with all the consequences related to scope, visibility and authority.

...

I realize that many of us, Enterprise Architects, our pay masters, and recruiters emphasize at times different aspects of EA. But they are all part of an Enterprise Architect's work day.

Here are the types: 

* EA Sell Justify (build business case) and sell EA 

* EA Design Architecture discovery and modelling 

* EA Strategic planning Roadmapping, Strategic planning 

* EA Operation Maintenance and EA compliance work 

And, in a way, each type requests a specific set of skills: 

Justification and sell use skills like the knowledge of the enterprise workings (KPIs), what makes them effective, how costs could be reduced... Also the business case specification implies some financials. Selling and communications require soft skills. 

Architecture modelling assumes methodologies like structured and OO analysis and design, a structured mind and disposition... Also a wide knowledge of technologies and architecture principles. 

Roadmapping and strategy skills are still an art form demanding an understanding of trends, business and IT strategy skills, planning... 

EA Maintenance demands project and solution architecture knowledge, change management, governance and organization skills, influencing, discipline, organized mind etc. 

...

Another outcome of the Enterprise Architecture conference in Sydney I recently participated to, was the positioning of the Enterprise architect as a leader in the transformation of the Enterprise and a participant in the business decision making process. All good news. Right now, this is not really the case although the trend may point in that direction.

But what is a leader or leadership for that matter? Let me point you to a recent discussion on HBS on this matter. What an interest this topic has raised! Latest thinking there points out that leaders must have theatrical qualities. I would say that actors becoming leaders are not rare, these days, especially in politics. But is it what leadership needs? I really believe that what is called theater is in fact another term for excellent communication skills, being able to hold an inspiring speech in front of your people or at a conference.

What is a leader? My take: An individual who leads a group's activity to a specific purpose. But these individuals could be selected, nominated, self-nominated or inheriting a leading position, a position of authority. In this case, a group may not even respect or agree with these individuals. The authority of this leader comes from the power of the position and political games. This is not what we mean by leadership in general.

What is leadership then? Leadership is the quality of an individual to attract followers for a specific purpose. For that a leader must inspire trust and respect coming from natural personal qualities, learned from experience or taught knowledge and skills. Leadership requires self confidence and emotional control. 

But it is possible to have a leading position without having leadership capabilities or the other way around. From here onwards, I would prefer to discuss the case of leaders capable of leadership only for keeping a simple and healthy tone of debate.

What are the qualities of leadership? Inspiring trust and respect is tantamount, even if the leader has a position of power, since there is little he/she can achieve otherwise. How to inspire trust and respect? In the first place, the individual has to be credible and lead by example; that will require top competence in that field of activity, a basic sine qua non condition for the leader. So the leader bases his confidence on knowledge and experience. How could confidence come otherwise?

...

The leader will have a vision, an ideal that inspires people and determines them to follow. He would be finding solutions where few can. A leader does the "right things" some say, but also should do the "things right", a good manager/administrator does.

A leader should be emotionally stable having a degree of Emotional Intelligence (EQ as opposed to IQ), so that he could understand, interpret and control emotion in others. But the leader is in control of himself first. A leader, alternatively, could be passionate to inspire his followers with his energy and enthusiasm. Which alternative do you think is right? ( believe it depends on culture: EQ is cool for the the Anglo-American culture while passion may be the norm for Latin cultures.

It is said that another way to inspire a followship is to act, as in theatre, i.e. play the role of a leader to inspire people. I do not believe this really works to the end although, nobody can deny, acting may have, sometimes, charming results, offering an alternative dimension to the grim reality. But in the long term the one who benefits is the actor, the "leader" and not the group. There is the difference between the role and the reality, the personage and the person. An actor is at his best when plays naturally since he is authentic i.e. there is match between substance and form. A mismatch is decoded by primitive but efficient detectors within ourselves: the eyes which do not smile or avoid looking you into your eyes, the gesture that does not confirm the words, the intonation gone the other way. 

Leadership needs authenticity to succeed, that is the image shown should fit the substance and competence. Authenticity means "you do what you say" and "you say what you think".

There are archetypes or worse stereotypes of leader types. The hero in films is a typical example. People are moulding themselves on heroes since early childhood. We struggle to imitate the best, their behaviour, we learn from them. There is also the stereotype of the business manager played by many, unfortunately. Someone who looks confident, decided, sure of success, looking the part but without the depth to deliver. 

The problem is that without the underlying professional ability, the confidence is wrong footed and the results average. The surrogate leader fails without knowing why since he is playing the role well and moreover believes in himself. Acting alone will not deliver professional results. 

In a culture driven by acting leaders the real work would not be prized any longer; meritocracy would be applied in terms of acting skills. An acting leader can empower, delegate but the immediate ranks feel the competence void and are tempted to step up the ladder. Then leadership will be maintained not by respect inspired by competence but through power, minute control and politics.

The style of leadership depends on field: a warrior leader would be bold and ready to fight, a president would be a decision maker, and a conductor would orchestrate the individuals in the orchestra. This would require different qualities.

Leadership depends on situation. A company in difficult times for instance. In normal times leadership is welcome but not in demand. 

Leadership does not necessarily means moral "good"; the proposed ideal appeals to followers good or evil. It is still leadership. There are evil leaders having their followers. Usually, they take on the good cause leaders.

Why people follow? Because trust, belief, the lack of doubt it is said to make people content, if not happy. Following is easier than leading. Too many choices or decisions makes us unhappy, it was discovered. People follow because of fear as well in order to get protection. 

Finally, leadership comes from will or desire to lead, since it is not solely a blessing but a very consuming activity, requiring sacrifice and dedication to the cause.