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. 🙂
A particularly interesting part is the emphasis on technical excellence. It is one of the extremely important aspects often neglected in Agile introductions. Among things like clean code, TDD, continuous delivery, the framework also describes the way we should deal with Architecture & Design in a very refreshing manner. Instead of creating additional organisational structure, roles and artifacts, Craig and Bas give a number of tips.
LeanArch.eu 