LeSS framework is basically Scrum, only scaled-up. It is more an additional set of rules and a really good explanation on how to apply Scrum in a scaled situation and still remain effective, than a framework on its own. This is especially evident when compared to other scaling frameworks. LeSS can be used to work effectively on a single product with multiple teams, and even thousands of developers.
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.
Think ‘gardening’ over ‘architecting’—Create a culture of living, growing design
This metaphor is intended as replacement for the building metaphor, which is usually used to describe what architecture means. The software systems are grown by incremental development, not built.
The rest is a large set of useful tips and direction of thinking when dealing with large scale Scrum. Here are few of these:
It is so important that every act of agile modeling and programming for the life of the system should be treated as an architectural act.
Standard whiteboards are possible but not usually sufficient–and in fact are often an impediment, because modeling is best done on vast open wall spaces without borders.
Encourage everyone to question and challenge all these assumptions [early architectural choices] and decisions, and to find ways to apply the lean thinking principle of decide as late as possible or defer commitment.
Technical leaders teach during code reviews.
Communities of practice (CoP) are an organizational mechanism to create virtual groups for related concerns.
Internal open source with teachers—for tools too
Don’t use stubs to delay integration
This should be captivating enough to make you visit the site.
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.
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. 🙂