Every single Enterprise Architect I know is or use to be an IT guy. Most of them are saying they are responsible for creating or adjusting processes, policies, flow of information, resource management and technology of their organisation. In reality, almost all of them are busy with technology, and maybe information part. At best, they are making nice pictures of business processes and information. There are certainly people responsible for execution of business strategy, but somehow they don’t call themselves Enterprise Architects. These people are often C-level managers or work for a policy department. “Enterprise Architects” might give advises to these people, but they are never part of the club. At least not in any organisation I’ve seen.
No matter how much we discuss term Enterprise Architecture – and there are really many of them, in reality it is always about making decisions about some combination of IT systems within one organisation seen from different perspectives (workplaces, software, infrastructure, integration, middleware, hardware, and so on). Enterprise Architects are very much concerned with processes, information flowing between departments and people, policies, strategy, but these are mere inputs for making IT decisions. At best, certain IT limitations or capabilities can influence business decisions in making or adjusting business processes.
Therefore, difference between Enterprise and Software is just a matter of scale and limited number of different aspects. The rest should be treated the same way. Btw, term software architecture in this context can be replaced with solution or system architecture. This distinction is also just as much relevant.
Let me explain. The first question would be: Which input is not relevant in creating either of them?
- Business processes
When creating a specific solution it is very much important that processes in specific software solution represent and are aligned with one or more business processes. - Strategy and Business Vision
One of the first things an Agile team does is get together with business people and define a Production Vision Board. One of the typical inputs here is a story from people responsible for strategy to explain the ultimate business goal. - Information
Domain-Driven Design is one of the most important practices in designing software solutions. The most important message of DDD is ubiquitous language. It means that terminology in code should be same as terminology used by business / users. In other words, developers are required to understand information on enterprise level, but only scaled down to their specific domain. Wether one defines Canonical Data Model, master data, reference data, or whatever terminology used, none of these are lacking in one software solution. Only terminology might be different. The difference is again only scale, and speed of change. Knowledge and practices in defining and partitioning information across different systems are same when defining one system.
Another question is wether concerns and practices are so different:
- Workplace, hardware, infrastructure, network
Any of these aspects are very much important when delivering a solution for obvious reasons. There are software / solution architects or teams only concerned with code, but that is just simply irresponsible in Agile environments. - Design practices
A nice example here are SOLID principles. I wish anyone who call himself Enterprise Architect could learn these principles. Especially when creating services in SOA. Our enterprise landscapes would become “clean enterprise landscapes”, just like we practice clean code. - Quality requirements
The same as for one system, the direction in enterprise landscape being formed is based on required quality requirements like security, capacity, availability, and so on. These might be different for different systems, but same rules apply to a single system. Some parts of one solution are allowed to be less available.
I could go on with many more examples, but I invite you to challenge me in this statement first. What makes Enterprise Architecting so special? Of course, you will need to agree on my definition of Enterprise Architecture first. 🙂
LeanArch.eu 
Hello,
Even though, as you mentioned, lot of skills / practices / methodologies are shared between enterprise architecture and software architecture disciplines, you forgot to mention a bunch of them that are different. For instance, “change management” skill is mandatory for an enterprise architect and not needed by a software architect (dealt by someone else in an implementation project), another one that I could mention would be the high communication skills that is needed by an EA (as you mentioned, the EA needs to talk to C-level, being able to summarize quickly, not being drawn into details), communication skill is needed at a complete different level for a software architect (discussing with his peers and with developers)
I could continue like this for a while…
So, NO, enterprise architect and software architect are not the same (neither the same people nor the same job) There are a lot of similarities, as there are a lot of differences… But as you know, the devils is in the details… 😉
To conclude, you may say that the software architecture discipline is a part of the Enterprise architecture discipline, that I would have a agree too. 🙂
BR
I understand your opinion. You are right that having people who properly deal with architecture on enterprise and software level is important. Communication skills are also extremely important. Although I know what you mean, but rather funny to ask people: “Do you have C-level communication skills?” when hiring an enterprise level guy. I don’t see why good communication skills are less important. They might be somewhat different, which is a problem on its own and certainly solvable by making sure that even developers talk to C-level people. Something that I’ve managed to achieve in several organisations as a coach, and specially C-level people were very glad afterwards.
Term “change management” have become extremely vague and over bloated in IT. It can mean many things.
Maybe a mistake in my post is that I mentioned in beginning “architect” instead of simply architecture, which is the main point. Skills people need for doing architecture on scaled level (enterprise) can be slightly different. Interesting thing to notice is that very often a group of senior hands-on developers from different teams are better capable of making enterprise decisions than many enterprise architects.
I actually tend to agree on this sort of definition as opposed to the “purer” concept of EA as a separate practice. As the old adage goes, “everyone is in sales”, so it is also true that every company is, ultimately, in the software business.
At the end of the day, every strategy, every automated business process, etc. are to be embodied in code, running on some servers, so it is bound to happen that both architectures will have to touch and share a lot, in fact.
Yes, communication skills are different (if you read carefully, I did not wrote “less important”)
When it comes to “change management” as most of the time with IT, the term has been miss used / blured… which doesn’t mean it is wrong. Might need to come back to the original definition… but that should deserve another post 😉 – not in comments –
Finally, I think we agree 🙂 both architectures (enterprise and software) are different. Needed skills are different… So why not making a difference? It would help not to mix / blur things, wouldn’t it? 😉
BR
I’ll give a few reasons:
1. We needlessly overcomplicate IT because of this.
2. People from enterprise learn too little from teams because they feel they are different.
3. It is limiting the empowerment of teams as one of the core Agile values. This limitation is one of the important reasons why Agile is not scaling well. The companies which solved this (like Spotify) have some really nice results.
In other words, there are definitely differences. But they are irrelevant compared to bad effects exaggeration of differences has on IT performance.
I was in a meeting few days ago in which there were 2 domain architects, one platform arch, one system arch, one software arch, a business arch and few others …
Being one of them I felt at best very silly.
I consider enterprise arch as a superset of all these skills, not as a separate thing. From distributed system arch to why not infra and ops. Think of the boxes of zachmann and you get the picture, maybe not a specialist in each but at least with a decent clue of each.
Prob is, as from first comment also, in almost none of the orgs and people I have seen ent archs can fit the bill. Lots are over 50s recycled mainframe progs, that talk in wordly abstractions, or worse mgmt consultants that have never wrote software …
Maybe we can’t just say that there is a lot of bad stuff around EA, due to both consultants, to elderly ones and to people that should go back coding time to time. Cause it would be to embarrassing…
This results that the average EA guy is usually scared off to go down to a squad babbering of their latest swagger crack.
All the wordly abstractions are appreciated only if they are traceable down to concrete items in each brain of the org, and same for all the nice pictures, patterns and so on so forth, that shall be traceable to system designs and coding through standard techniques such as archimate.
The avg answer is: oh we are happy about our business services but no we are not intersted to map them to technologies, implementations, infra, to delve into interfaces, detail out models and so on ..
Maybe it becomes too much an easy job this way ?
With a bit of practice I can teach my wife the wordly talks, acronyms and fancy names … and she will be able to do as well as these guys… But ops .. it will not be so easy for her to spot if that piece of commercial package integration hits the owasp and is a no no for a specific case.
Maybe these bad woods chopped out the easiest spot, and now are on their way to the door cause their CIO is pissed …