Difference between Enterprise and Software Architecture is artificial

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.

Image

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. 🙂

Agile and Scrum in Hong Kong

In short, Agile is starting to take off in Hong Kong. Others might say, it is not really happening here (yet), depending on how optimistic one is. While in America, Europe and even other APAC countries, Agile software development is widespread, Hong Kong is a quite different story.

Image

Dinner and gala for ICT CEOs of Hong Kong.

Why? There are several reasons. Most people associate Agile and Scrum with software development, and there are less software development companies and software developers in Hong Kong compared to neighbouring countries. It seems that most software for Hong Kong customers is developed in India or Singapore.

Another reason could be cultural. Software development as craftsmanship seems to be less valued in Hong Kong than in other countries. Also, there is this obvious hierarchy, where management takes decisions and subordinates follow up. Actually, this seems to be only the symptom of much deeper difference with e.g. Europeans. Higher ranking people, both in private (parents and other older family members) and business life, are much more respected than in Europe. This very nice cultural aspect, has a pitfall. It is quite difficult for teams to take substantial decisions without simply asking the boss what she wants. This makes introduction of self-organising teams easier if management actively and continuously approves and (co-)facilitates the coaching process.

Hongkongers are hard working people. Working more than 40 hours a week is very normal. Children are brought up in relatively protected environment, where hard work and obedience are being rewarded. Typical Agile guys in self-organising teams are rather assertive and opinionated, and don’t really like working hard. Instead, they like to continuously improve effectiveness of their work. In other words, achieve more while doing less. There is of course nothing wrong with working hard. It is just that in order to be more effective, very often we have to slow down and retrospect on what is happening. This might feel like waste of time and awkward.

Also, people are very eager to learn new things. Preferably by listening to a lecture or some other form of teaching. Unfortunately, there is not much to learn about Agile and Scrum unless you actually start doing it as soon as possible. Becoming Agile is more about learning from experience, and less about learning from others.

I’ve also wondered if delivering a software solution here in waterfall approach is simply more successful than in Europe or US. Therefore, an Agile approach with faster delivery would simply not be needed. That is definitely not the case. The problems with disconnected business, large IT projects, mostly outsourced and managed with thick contracts are same as anywhere else.

Comments on the subject are very much welcome.