Summary
Empathy is commonly defined as the ability to directly share another person’s state of mind: feelings, emotions, understandings, etc. Such concrete aptitude would clearly help business analysts trying to capture users’ requirements; and on a broader perspective it could even contribute to enterprise capability to foretell trends from actual changes in business environment.
Analysis goes in the opposite direction as it extracts abstract descriptions from concrete requirements, singling out a subset of features to be shared while foregoing the rest. The same process of abstraction being carried out for enterprise business and organisation on one hand, systems and software architectures on the other hand.
That dual perspective can be used to define alignment with regard to the level under consideration: users, systems, or enterprise.
Requirements & Architectures
Requirements capture can be seen as a transition from spoken to written language, its objective being to write down what users tell about what they are doing or what they want to do. For that purpose analysts are presented with two basic policies: they can anchor requirements around already known business objects or processes, or they can stick to users’ stories, identify new structuring entities, and organize requirements alongside. In any case, and except for standalone applications, the engineering process is to be carried out along two paths:
- One concrete for the development of applications, the objective being to meet users’ requirements with regard to business logic and quality of service.
- The other abstract for requirements analysis, the objective being to identify new business functions and features and consolidate them with those already supporting current business processes.
Those paths are set in orthogonal dimensions as concrete paths connect users’ activities to applications, and abstractions can only be defined between requirements levels.
As business analysts stand at the crossroad, they have to combine empathy when listening to users concerns and expectations, and abstraction when mapping users requirements to systems functionalities and enterprise business processes.
Architectures & Alignments
As it happens, the same reasoning can be extended to the whole of engineering process, with analysis carried out to navigate between abstraction levels of architectures and requirements, and design used for the realization of each requirements level into its corresponding architecture level:
- Users’ stories (or more precisely corresponding uses cases) are realized by applications.
- Business functions and features are realized by services (assuming a service oriented architecture), which are meant to be an abstraction of applications.
- Business processes are realized by enterprise capabilities, which can be seen as an abstraction of services.
That matrix can be used to define three types of alignment:
- At users level the objective is to ensure that applications are consistent with business logic and provide the expected quality of service. That is what requirements traceability is meant to achieve.
- At system level the objective is to ensure that business functions and features can be directly mapped to systems functionalities. That is what services oriented architectures (SOA) are meant to achieve.
- At enterprise level the objective is to ensure that the enterprise capabilities are congruent with its business objectives, i.e that they support its business processes through an effective use of assets. That is what maturity and capability models are meant to achieve.
That makes alignment a concrete endeavor whatever the architecture layer, i.e not only for users and applications, but also for functions and capabilities.
Enterprise Fourth Dimension
Enterprise Architectures can be fully described as a cross between layers (platforms, systems, organization) and processes (business, engineering, operations). But the validity and usefulness of such outlook is contingent on homogeneous and stable semantics:
- Homogeneous: some conceptual consensus can be sustained across business units.
- Stable: some continuity and consistency can be achieved for the mapping between business objectives and targeted environments.
Meeting those conditions may become problematic with the growing part played by services and the crumbling of fences between enterprises and their business environment. In that case alignment will have to rely on a fourth conceptual dimension.
Great information and context. Thanks for sharing!
Very clear Remy! Makes “alignment cheking” excpectation more concrete to me in a way I didn’t see yet.