Random Thoughts

Some random thoughts on enterprise and software systems architecture, and what comes into mind when dealing with these ...

Dividing the Enterprise

posted Sep 24, 2023, 10:45 PM by Alar Raabe

“Divide et Impera” – break down a problem into two or more sub-problems of the same or related type, until these become simple enough to be solved directly.

Because enterprise is usually very big and complex system, we need to decompose it – divide it into manageable pieces for any analysis or design activity, and for efficiently organizing and managing the multitude of the elements that are identified and used for describing the enterprise from various viewpoints.

...

It is usual, that different disciplines, which deal with the analysis and design activities of an enterprise from different viewpoints and for different purposes, divide the whole enterprise based on their primary interests and according to the main methodologies in their area, organizing the elements that describe the enterprise according to different criteria.

This could be illustrated for couple of such disciplines (process modeling/management, information modeling/management and applications modeling/management) for example as follows:

Because for both analysis and design these elements are usually needed to be viewed/described in their context(s) (e.g. processes create and use some information and are supported by certain applications; applications master, provide and consume certain information; etc.), this leads to the need of connecting the elements identified/used by different disciplines, to avoid creating several separate and possibly inconsistent views on the same enterprise.

This all leads to the following problems:

Multiple different decomposition hierarchies will be created, from different viewpoints, for different purposes, and by using different methodologies, and these are usually created/maintained by separate communities of practice – this tends to lead to multiple inconsistent and non-reconciled views on the (same) enterprise.
It will be difficult to decide upon the primary decomposition hierarchy, which should be used to organize the whole picture (and all its elements), because of the different interest groups / stakeholders, different communities of practice and different methodologies used to create these decomposition hierarchies – this will lead to the situation, where each of these disciplines tend to maintain their own context(s) needed for their primary elements, creating duplicate representations, neither of which provide the holistic view of the enterprise.
Due to the need for context, multiple different type of relationships will be crossing the various decomposition hierarchies to connect things on right hierarchy levels – such relationships are usually difficult to maintain, as different ends need to be agreed by different communities of practice and there’s no natural master/owner for the relationship.
Because the relationships that cross the different hierarchies are most often connected to the leaf elements of these hierarchies, all decomposition hierarchies need to be fully developed until the relationships that cross the decomposition hierarchies can be created – which leads to the need of coordinating large efforts between the different communities of practice and difficulties in sequencing these efforts (e.g., due to the circular dependencies).
In several of the disciplines of analyzing and developing the enterprise, there is an additional problem, making creation and maintenance of these decomposition hierarchies difficult – from certain decomposition level the main element and sometimes also criteria for decomposition change.
For example:
- processes on different decomposition levels are rather different things (therefore apart of the name also the level number becomes important to understand what we are dealing with) and the leafs of process hierarchies are usually tasks and other elements, which are not processes at all;
- information decomposition starts usually with the subject areas, progresses to entities and ends with the attributes;
- application decomposition also starts with the groups of applications, progresses to the applications and depending on the needs and methods might end with several levels of application components;
- etc.

To avoid all these problems we should decompose the whole enterprise only according to one criterion, and do this recursively, breaking the enterprise into the self-similar smaller pieces (self-contained parts of the enterprise), which could be thought of possible to completely outsource to some other enterprise (if needed). Only at the final level of decomposition, in the leafs of such decomposition hierarchy other elements, that describe the enterprise (or parts of an enterprise), appear. Therefore such decomposition will collect together and organize according to the same schema all the various elements used in the analysis and design of the enterprise.

Such decomposition could be represented as follows:

And this leads to the following benefits:

Only single decomposition hierarchy to maintain – easier governance, and on every level of decomposition we will have a holistic view of the particular part of the enterprise, containing all the necessary elements for analysis and design.
Same single decomposition could also be used to conduct and present strategic analyses on the enterprise (e.g., using “heat-mapping” to identify places where the changes are needed and will provide most strategic value, etc.).
Only the relationships of single type “serving” are crossing the decomposition hierarchy levels (i.e., are showing how various parts of the enterprise are serving each other), and all the other relationships between the elements are nicely contained within the particular part of the enterprise – which leads to easier maintenance of such relationships.
Such networks of parts inside the enterprise form a value network (as opposite to the set of linear value streams used by many other methodologies), which gives a more realistic picture of the value creation inside the enterprise.
The decomposition hierarchy doesn’t need to be fully developed for describing:
- the relationships between the “leaf” elements, as these all are contained in a single part of the enterprise, and
- the relationships that cross the decomposition hierarchy levels, as it would be possible to start from the derived/compound relationships between the higher level parts and decompose such relationships according to same criterion as the whole enterprise is decomposed.
Due to that it will be possible to organize the work so that detailed representations of both the parts of the enterprise and the relationships between those parts are developed “on-demand” (i.e., only for these places in the enterprise that need it due to the analysis needs or planned change).
The task of coordination between the different communities of practice and stakeholders is simpler and analysis and design tasks themselves become smaller due to the division of work following the decomposition of the enterprise – because all different interest groups / stakeholders and different methodologies work together on the holistic picture on every level of hierarchy, and due to smaller tasks/efforts concerning single parts of the enterprise.
When created, such hierarchical decomposition becomes a “blueprint” for the ideal organization for the given enterprise, which would give hints for and could drive the development of overall organization.

Such decomposition method has been earlier described and employed for example by:

IBM as Component Business Model, where the self-contained parts of enterprise are name “business components” (see IBM Component Business Models. Making Specialization Real and IBM banking Architecture) and
BIAN as Service Landscape, where the self-contained parts of the enterprise are named “service domains” (see BIAN Semantic API Practicioners' Guide).

Although in some cases business capabilities are defined nearly the same way (see Archimate 3.2 Capability and TOGAF Business Capability), many business capability models are built in such a way that business capabilities in these models cannot be viewed as self-contained parts of the enterprise (which could be possibly outsourced), therefore not representing holistic parts in the recursive decomposition of whole enterprise.

A good description of the problems involved by negotiating such business capability model with the decomposition of the enterprise done according to the way, described above (i.e., Service Landscape) is provided lately by BIAN (see BIAN BCM Relationship with BIAN Service Landscape).

…

Architectural change

posted Aug 21, 2023, 11:48 PM by Alar Raabe

Lately the question of what is an architectural change of a software system, has popped up in various discussions. The answer to this question guides the involvement of architects in systems development, and architecture governance and documentation.

I would say, that if we base on the well-known definitions of software architecture, only certain kinds of changes could be considered as changes of architecture, independent of how big in terms of effort the change is.

...

So, what we should consider as an architectural change of the software system?

In many previous works on software systems architecture, the architecture has been defined as consisting of following three parts:

a set of the components (or elements) of the software system,
a set of the connections (or relationships) between the components themselves, and between the components of the software system and its environment,
a set of rules and principles guiding the design and evolution of the software system (incl. rules what kind of components, and what kind of connections the software system can contain).

For example the definition of (software system) architecture, adopted by many standards organizations, the (software system) architecture is "fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution" (e.g. ANSI, IEEE and ISO).

That definition, which is revolving around building a structure for certain purpose, is well in sync with the definition of architecture in civil engineering (by which the discipline of software architecture is inspired), where architecture is mainly seen as “the art or practice of designing and building structures and especially habitable ones” [Merriam Webster].

Although the latest incarnation of the ISO standard on systems architecture description [ISO 42010:2022] has for some reason dropped “elements and relationships” from the definition of system architecture, I will stick with the previous definition, as the elements and their relationships of the software system, which representing how the software system is built, are the most important things to consider in the context of the change of the system.

To clarify what is the architectural change, we need to bring in one more concept – the architecture style – which represents what is architecturally common to a family of software systems, being a kind of design language for the software system architectures, and is usually seen as consisting of following things [Garlan & Shaw, Shaw & Clements and SEI CMU]:

a set (or vocabulary) of component types,
a set (or vocabulary) of connection types,
set of constraints/rules, which need to be true for all the architectures in given architecture style.

Well known architecture styles are for example: data flow (a.k.a. pipes and filters), data centered (a.k.a. repository) repository, layered systems, etc. [Garlan & Shaw].

Now, based on these definitions, we can define what we mean by the change of architecture (or architectural change) of the software system.

Following kinds of changes of a software system can be considered as changes of the architecture (or architectural changes):

adding a new or removing an existing component,
adding a new or removing an exiting connection, and
adding a new or removing an existing rule or principle guiding the design and evolution of the software system.

Two first ones are simple and local, because they do not affect the architecture style of the system, but the last one is in nature complex, as it can affect the architecture of the system globally, and can lead to the change of the software system architecture style (e.g. by changing set of allowed component and/or connection types, and the way how the software system can be built using the components and connections).

Simple description of architectural changes could be given by coloring the corresponding elements on the diagram ("green" for additions and "red" for removal):

Defining architectural change this way means for example, that if the existing rules and principles of a software system architecture allow implementation of components on several platforms, then reimplementing an existing component on different platform, allowed by the architectural rules and principles, is not an architectural change. But if the new platform is not yet included into the architecture rules and principles and will be by this change, then this change is an architectural change.

If the change is such that the meaning/purpose of one component or connection has been changed, then this must be considered as being equal to the removal of the old component or connection and introduction of a new component or connection.

A good example of the later case is (a rater usual case of) change of the core schema of a central database (or repository) of a repository-centric system in case there has not been established any interface schemas for connections with the processing components of the system or otherwise insulating those from the central database (or repository), we in architectural sense actually replace one (in this case very central) component and all its connections to all other components.

Therefore one, seemingly small, change becomes actually a massive architectural change, affecting whole system (causing cascading changes and possibly leading to many unanticipated side-effects).

If we consider the simple measure of the complexity of software system the number of components and connections (see Complexity in/of the enterprise architecture), then this way of treating the architectural changes allows us also simply measure the effect of the changes to the complexity of the architecture, by the added/removed components and connections.

Although the reasoning above is about the architecture change of the software systems, the formulation of systems architecture as a set of components, their interconnections and rules of composition, does not rule out any other types of systems -- so we can apply same definition of architecture change also to the business system (or to the combinations of both business and technology systems).

Thoughts on architecture and agile methods (in the example of SAFe)

posted Feb 07, 2023, 10:53 PM by Alar Raabe

Agile software development pactices try to embed the design of the sofware system architecture into other development activities, instead of doing it as a separate activity.

Although the software system architecture can be developed in various ways, there are some implications if this happens incrementaly and is driven by random stream of requirements.

...

So what's the relationship between architecture and agile methods, if there's any?

If we take the definition of (system) architecture adopted by many standards organizations, which is "fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution" (e.g. ANSI/IEEE/ISO 42010), then we could rest assured, that whatever is the method or way of developing the software system, it will always have an architecture – that is, architecture will emerge when we develop the software system.

From the studies of the different styles of software architecture we can see that software systems, that peform the same function, can have rather different architectures – so why to bother?

The problem is raised, because apart form the function that software system performs, we often are interested of some other properties of the software system (usually specified as non-functional requirements towards the software system), and because software system architecture is the cause of many important properties of the software system, which are usually requested by several stakeholders.

The core of the agile methods is to design and build the software systems piece-wise, but while the functionality of the software system is usually possible to divide into pieces or decompose rather easily, the software system architecture, being a set of global structures, affecting the software system as a whole, does not lend itself to such treatment. Usually some global structures, that define the software system architecture need to be first developed and completely built (at least up to certain level of completeness), to be able to implement the pieces of the functionality (i.e. system functions).

SAFe represents the larger pieces of the system functionality (or system functions) by the capabilities, which themselves can be decomposed into smaller pieces of functionality, called features (see Features and Capabilities in SAFE).

Admitting the insufficiency of the emerging architecture alone and agreeing to the need for the intentional architecture of the software systems, SAFe proposes an Architectural Runay as implementation of software system architecture (i.e. the code and infrastructure needed to implement the features), which can be itself evolved/extended by implementing the Enablers.

So far so good, but to be able to divide the work so that we can build first just a part of the software system architecture, needed for a set of features, we need to be able to map these features onto the software system architecture, for which we need the full architecture designed first.

Therefore, in the best case, we can build the implementation of the software system architecture piece-by-piece, but before that we need to design it as a whole. Another slight complication is the global nature of the software system architecture structures – if for any reason we need to change the software system architecture in such a way that is not supported by the extension mechanisms of the existing architecture of the software system, we need to implement the new software systems architecture an then re-implement/-build all the features that have been built so far (because the system architecture defines how the features are built). All development teams try to avoid later as long as possible, as a very costly exercise.

Another complication arises from the fact that, if the overall software system will be designed and developed incrementally as a response to the stream of requirements stated by the stakeholders, the software system architecture will very much depend on the order in which these requirements arrive.

For example if we build the communication system (e.g. a chat system) and the requirement for high security of personal information and communications is received within the first requirements, this might lead to the selection of an architectural style of independent components, where none of the components has complete knowledge of all the users and communications within the system, but if this requirement is not received early enough, then it would be natural to select the architectural style with central reporsitory for users and communications.

When now the requirement for high security of personal information and communications arrives, there could not be possibility to completely re-implement the system according to different architectural style, and therefore architects might select compensating techniques, adding encryption fo a central datastore, leaving the architecture of the system same (which will not meet the requirements in best possible way).

Using ArchiMate for modeling ...

posted Nov 9, 2020, 10:08 AM by Alar Raabe

ArchiMate language does not distinguish between types and instances.

Because among the enterprise architecture models there are both type and instance models (sometime it even makes sense to put both types and instances on the same model), some technique must be used to distinguish between types and instances.

...

Recently I stumbled upon a strange „feature“ of ArchiMate language that brings some ambiguity into the models.

In the ArchiMate specification (see Open Group ArchiMate 3.1) chapter 3.6 is written „The ArchiMate language intentionally does not support a difference between types and instances.“.

This design decisions brings ambiguity into the meaning of the diagrams. For example, what is described inthe following diagram:

Does this mean that:

„There exists a set of data objects of type A, each consisting of 'one-or-more' data objects of type B, and 'one-or-more' data objects of type C“, or
„There exists a data object A, which consists of data object B and data object C“, or even some mix like
„There exists a data object A, which consists of 'one-or-more' data objects of type B, and a data object C“?

There are situations, where it would be possible to deduce, whether diagram is describing the types or instances (because for example certain reflexive relationships, like „composition“, would not make sense for the instances), like:

But in some cases it would be impossible to know without some indication of what kinds ofelements are in the model or on the diagram, like:

Therefore indicate the usage of types or instances explicitly, using for example through ArchiMate specializations (similar to UML sterotypes) and the naming convention similar to UML, either for the types:

or for the instances:

Although in ArchiMate specification it is stated that „At theEnterprise Architecture abstraction level, it is more common to model types and/or exemplars rather than instances.“, there are still many cases where the model of the actual enterprise architecture consists of instances (like capability maps, process maps, or application landscapes, which all represent certain enterprise portfolios), and therefore it makes sense to clearly indicate on the diagrams, where are the types (for example when describing conceptual models or solution patterns) and where are the instances, especially if both are mixed on the diagram.

Hierarchies with the single elements and fixed levels

posted Nov 8, 2020, 10:58 PM by Alar Raabe

There is certain wish, when handling the hiertarchies, to fix the numer of levels, with the reasoning that this should make things simpler and clearer.

This leads to the hierarchy levels whichj contain only single element, which could make sense in the class/type hierarchies, but does not have any meaning for the composition hierarchies.

...

I have seen many times the wish to fix the number of levels in the decomposition hierarchies (like for example in the maps of business capabilities), with the reasoning that it would make things easier by always having known number of levels. One result of this approach is the appearance of branches with single elements on certain levels.

There are such hierarchies, where the elements with just one sub-element will make sense, and there are other hierarchies, where this doesn’t make sense.

For example in case of taxonomy, each element is representing a set of features – it is a class hierarchy.

In the class hierarchy it makes sense to have even single sub-class for a particular class, because this sub-class represents a different set of features than its super-class. It also could make sense in class hierarchy, if needed, to have a fixed number of levels – because on each level of each branch you have different set of features (which you can distribute evenly).

It makes sense to have:

either , or .

On the other hand, in case of functional decomposition,like hierarchy of business capabilities or application components, each element is a whole – it is a composition hierarchy.

In the composition hierarchy(which consists of instances, not of classes) it doesn’t make sense to have an element that has only one part, because these are then the same thing.

It makes sense to have:

, but not

It also would not make sense in the decomposition hierarchy to have fixed set of levels – because this would either enforce the designers to come up with "dummy" levels just to follow the scheme, and results decomposition that is not natural, causing branches with single elements just to „fill“ the levels of hierarchy, introducing multiple ways to name what actually is the same thing.

This is the reason I wouldn't advise to create for example business capabilities with only one sub-capability or application components with only one sub-component.

Using models in software development ...

posted Jun 7, 2020, 4:30 AM by Alar Raabe [updated 4 Sept, 2023, 5:15 PM]

Compared to the beginning of software engineering, the current practice tends to diminish or completely drop the use of models (formal represenation of requirements towards the software system).

But if there's any wish to automate the software development activities beyond the simple pipelines of build tools, there is need for the strong formal models that specify what to automate.

...

I see more and more, that the usage of models (referring to traditionally used qualitative, often graphical, models and modeling languages) and model building is diminishing in the software engineering (if we can talk about the software "engineering" anymore at all).

The reason seems to be that developers do not want to use the models and therefore making or maintaining these is perceived as "no-value" overhead. Behind the reluctance of developers to use models is often the agile movement's argument that everything could be seen/found from the code, and because in DevOps same team that does the development, does also maintenance, there’s also no need to communicate between different teams.

But actually:

it is very difficult, if not impossible, to write code so that all the requirements or high-level design decisions would be presented directly in the code (not to mention being easily readable/understandable for the ones that did not write the code),
it costs time and money if developers make mistakes because they are not able to understand from the code the requirements it implements and the design intents/constraints, and
it costs even more time and money if developers go away and need to be replaced by new ones who don’t know anything what has been said "at the water-cooler" (possibly two or more years ago).

Because additional information (same that has been traditionally represented by the models) is needed and because code isn’t usually very much commented and often also not very readable,so often developers and others, involved in the software development activities, try to find other ways to collect and maintain this additional information, representing it usually in non-formalized textual form in their work-organization tools (e.g. Confluence wiki and in Jira tasks).

Additional reason to drop models in the software development in favor of informal textual descriptions, seems to be the inability to automate anything in software development process apart from the simple "automation" of build tools to manipulate software artifacts in correct succession (thing that has been around already past 60 years) – so there’s no perceived value to have requirements or high-level abstract knowledge about the software to be represented in machine-readable form.

Today still a very big part of the development of business software is solving rather standard/common problems and is filled with the repeating tasks, which are very easily automated (like development of GUIs (where they are not the distinguishing factor), integrations, transformations, reports, etc.), and doing so would economize a lot of development time, but this will be only possible, if the requirements and high-level design would be formally specified and represented in a machine readable form.

So, the main question is "Dowe want/need to automate also our software development activities?", or do we just want to automate only the various business activities and continue with manual software development?

If we want to automate software development (i.e. digitalize the software development), we need a formal, machine readable, representation of requirements and high-level designs (with the focus on formalization and machine readability, not just some pictures with "boxes and arrows"), in the same way as for example to automate the credit origination, we need formal representation of customer, loan, collateral, sales process, involved business rules, etc.

Lately the question of automating the development of software has turned towards AI (using large language models trained on the existing code).

The problem with this approach is, that because the models developed by the machine learning are non human-readable and non-transparent to the users, the way to control and guide the generative AI is via prompts, which quickly becomes rathere similar problem as controlling and guiding the human developers through the natuaral language (which is ambiguous by nature).

Business Capability – a short clarification

posted Jun 19, 2017, 2:54 AM by Alar Raabe

A "business capability" describes ability to perform certain set of related activities for providing a set of business, by combining people, processes, resources and governance.

Business capabilities are connected to other business capabilities through the business services and form a value network.

...

The term “business capability” is synonymous with BIAN “Service Domain” (see BIAN Practitioners Guide), with “business component”in IBM’s CBM methodology (see Component Business Models), and with “business function” in general business management.

A “business capability” describes ability to perform certain set of related activities for providing a set of business services, by combining people, processes, resources(incl. needed technological systems) and governance, using the business services from other business capabilities, if needed.

Where “business service” describes externally visible unit of business functionality of a business capability, which provides value to service consumers, is provided via explicit external interfaces, and realized by business processes.

You can think of a business capability as a self-contained part of business that could be outsourced as is.

Business capabilities themselves can be hierarchically sub-divided into smaller business capabilities if needed, or combined into larger business capabilities up to a business capability to provide all the services of a certain business (for example to provide all banking services).

Business capabilities are connected to other business capabilities through the business services and form a value network.

The business capabilities for a given business domain can be found/formulated, taking as the starting point the lists of key activities needed for all the business models of given business domain. The set of business capabilities describes what things given business domain must be able to do, to support the business strategy and execute the business models.

API vs. ESB (and other related tools)

posted Jun 16, 2017, 1:04 AM by Alar Raabe

I would like to clarify some questions related to API management, ESB and specific service interfaces.

From one side, API (Application Programming Interface) is nothing more than a specification – a text, containing a set of more or less formal statements, which specify the available (service) operations and data that flows through the interface when these operations are performed.

Therefore managing an API is nothing morethan managing any other formal document – which can be done using any basic text editor or something more fancy, called API management tool, with lots of bells and whistles and with heavy price tag.

From another side, ESB is nothing more than a system that transports and routes service requests, and returns matching responses, usually providing several different physical mechanisms to do so, independent of how these service requests are defined or do they together at all form an API.

Therefore, if we implement API management tool and ESB, then this will not in any way result in a specific API (or service interface).

Developing a specific API is quite time-and resource-consuming task, which needs to be planned and designed as anyother large development. What makes API design even more important, is that API's guide the architecture of future developments and affect strongly their properties.

A good analogy here is with DBMS and actual database schema – although we have tools for designing database schemas(e.g. ERwin) and DBMS to run these schemas (e.g. Oracle or TeraData), we cannot assume, that database schema (e.g. for Enterprise DW), suitable for current and future needs just emerges from separate developments. It needs a special (some-time very large) effort, to develop a suitable concrete data-base schema.

API design and development requires same way as data-base schema design and development:

conceptual models for both functionality (service operations) and data (information),
logical models that specify the interfaces, and
physical models that specify the interfaces for specific implementation technologies.

And the above mentioned artifacts are not produced neither by the API management tools nor by ESBs.

Thoughts on "Architect Your Business - Not Just IT"

posted Apr 13, 2015, 8:23 AM by Alar Raabe

When reading MIT CISR Research Brief No 12 from 2014 "Architect Your Business - Not Just IT", I agree very much with the statement that “… despite the title, business architects rarely design their company’s business.”!

The main puzzle for me is, that even when everybody in the organization sees and agrees, that “…their processes, structures, and systems are not providing the agility they need …” (i.e. the business architecture of the company is not adequate), I don’t usually see any dedicated effort for designing a new business architecture, not to mention employment of a specialist with business architect skills for doing that.

Here I must agreeagain with the statement that “… the dominant design approach for large companies is ‘divide and conquer’ in which individual leaders accept responsibility for success over a specific set of closely related business activities.”. Because of the Conway's Law, this approach leads to a business and IT architectures that copy the power-structure of the organization.

The above mentioned approach could work, but only if the domains of power and integration/interaction points between those separate “kingdoms” are very clearly defined and controlled, and designing these interfaces and controls should be the main task for the actual business architect.

Complexity in/of the enterprise architecture

posted Dec 30, 2013, 2:10 PM by Alar Raabe

The negative effects of the overall complexity of business and IT in the enterprise, manifest themselves as unreliability and excessive cost of operations, and excessive cost and time to make changes.

Business complexity has additional negative effects due to the difficulties in selling more complex products and customer dissatisfaction due to unclear and time consuming business processes.

Therefore complexity of the business and IT in enterprise needs to be controlled and managed.

To be able to control and manage the complexity, we need to be able to measure it.

If looking into different treatments of the complexity of systems, we can define the complexity as

the number of different elements and their interconnectedness (number of interconnections between these elements).

Based on such definition, we propose to measure business and IT complexity by counting the elements of business (like business models, customer segments, offered products, business functions, business services, business processes, etc.) and IT (like data stores, applications, technologies, etc.), and their interconnections.

In both business andIT we can differentiate between:

external complexity, caused by the external factors that are notunder our control or depend on large scale strategic decisions (that define in which business the enterprise is in), which cannot be reduced without the large changes in the enterprise business strategy, and

internal complexity, caused by our tactical choices and decisions of how we organize ourselves or how we operate (that also defines the complexity for the customers), which can and should be reduced to improve the overall efficiency and agility of the enterprise.

The internal business complexity (e.g. how we organize or operate the business) defines also large part of the external IT complexity, the other part being defined by the external technological factors.

Extending EA meta-models to contain the environment ...

posted Jul 29, 2013, 1:55 AM by Alar Raabe

Current EA meta-models describe in great detail the internals of the enterprise, but leave the environment in which the enterprise operates either totally out, or describe it in considerably less detailed way.

There are definitely some meta-models, for example Nick Malik's EBMM (contains Influencer) and new ArchiMate motivation extension (contains Driver), which try to deal with the (inconveniences) of outside world, but this is not that elaborate and structured, as these parts of meta-models which deal with inside world.

If we see the role of EA function as supporting the orientation of the enterprise according to John Boyd's OODA loop, there is need to have sufficiently good models for both representing and interpreting the environment, and representing and interpreting the enterprise itself.

We should add something similar to the dynamic financial analysis (DFA) models to the EA meta-models, to be able represent the impact of environment to the enterprise, as elements representing competition, markets, regulations, etc. (see for example A. Bergbauer, V. Chavez, T. Fischer, R. Perera, A. Roehrl, S. Schmiedl, Back to the future: Dynamic Financial Analysis (DFA) for decision making, 2004 (Fig. 3), or M. Eling, T. Partnitzke Dynamic Financial Analysis: Classification, Conception, and Implementation, 2005 (Fig. 2), or M. A. Taylor, Business Environment Model, 2013).

Do/should we have "internal customers"?

posted Jul 24, 2013, 2:53 AM by Alar Raabe

If we use in the enterprise architecture framework IBM Component Business Model (CBM) and A. Osterwalder's business model canvas (BMC) for describing the business and its parts in a business domainarchitecture.

The CBM can be used to describe the overall business functionality and the functional decomposition of whole enterprise into business components, which can be viewed as small independent businesses. The business components in a CBM are connected through the business services that they produce and/or consume from the other business components, forming a value network. Some of those business services are produced and/or consumed by the external parties (including the enterprise’s customers). So from that viewpoint, for every business component, an external (to the given business component) party could be in two different role – customers/consumers of the produced services and suppliers/producers of the required services.

The A. Osterwalder’s business model canvas can be used to describethe overall business logic of how the business works for whole enterprise, and/or for each functional sub-division down to the business components, identified in the CBM. Business model canvas also identifies external parties in two different roles – partners and customers. This separation is beneficial because business usually needs to employ different relationship management techniques for the external parties playing those different roles, and usually also the channels through which the value is delivered to the business, and through which business delivers value, are different.

Above described conceptual models (together with their language) provide the modularity and encapsulation, needed to manage the inherent complexity of the business functionality that whole enterprise comprises. Employing this view in business organization/operations allows us to achieve self-optimization of the operations of whole enterprise by optimizing the operations of separate business components, and robustness by encapsulating the business components behind the well formed service agreements.

In principle we should be able to separate and replace any business component (including IT or its parts) as an independent business entity, without changing the internal workings of that particular business component and affecting the operations of overall value network.

So in the behavior of a business component, there should not be any difference, whether the external (to the given business component) party is also external to the whole enterprise or just another part of the enterprise, but the business component should definitely have different behavior (down to the clear service agreements) towards the parties to whom it delivers services and towards the parties that deliver services to it.

To avoid confusions with the usage of word “partner” in the A. Osterwalder's business model ontology it would not be good to denote such business components, which do not directly deliver services to the enterprise’s customers, with the same word “partners”, for both consumers of their services and suppliers of services they need.

There might be political reasons for which we want that in our language enterprise’scustomers should stand out from business components that are internal to the enterprise, and because the value network inside the enterprise uses different ways to account the value, the word “internal customer” might not be appropriate for consumers of internal services.

So should we then use the word “consumer” throughout the enterprise architecture models/descriptions to denote the business service consumers in the business models instead of word “customer”?

In case the same business component provides the same business service to both enterprise’s customers and other business components in the enterprise (as in many cases IT related business components do), should we treat those as two different service consumer classes, and use different words to denote these?

Reducing the complexity and increasign the modularity ...

posted Apr 22, 2013, 8:26 AM by Alar Raabe

... of enterprise systems, based on the results from (The Evolutionary Origins of Modularity), could be achieved, by imposing an additional cost (a kind of "tax") upon the direct connections between the enterprise systems.

Reserves created from such "tax", could be invested into the improvement activities of enterprise architecture.

Controlling the enterprise (IT) architecture

posted Feb 27, 2012, 11:10 PM by Alar Raabe

We can control/develop enterprise (IT) architecture by following:

using Conway's law -- enterprise organization should be designed such that we would like the enterpise IT architecture to become -- there must always exist an interested party for developing certain architecture feature/element (e.g. developing the architecture in certain way must be in somebody's interest);
limiting the resources in suitable manner would stimulate thinking and (as a consequence) reduction of complexity, increase of reuse, and simplification of maintenance -- that is architecture can be developed by the owner/steward of necessary resources -- in case we have a governance body for architecture like architecture committee, it must own or command resources;
ownership of main (architectural) principles by top management (they must belong to the enterprise identity and value system) -- only then they will influence the architectural decisions;
differentiated actions according to the governance model:
- in the enterprises with strong central governance (power) it is possible to design the architecture according to certain goals, and the result would be foreseeable,
- but in the enterprises with weak central governance (power) or completely decentralized enterprises it would only be possible to create favorable situation for architecture to emerge and develop (grow), and the result would not be foreseeable nor guaranteed;
differentiated capital investments -- the part of the architecture, which function is most static (i.e. infrastructure/platform) could afford the biggest capital investments -- to stay long time without changes it must perfrom very generic functions (as an opposite to the frequently changing parts of the architecture which could perfrom very specific functions) -- the more variable/volatile is the function, the smaller should be the capital investments;
limit the amount of "technical debt" allowed for the IT architecture -- large technical debt limits the options of change and "takes over" control of the architecture.

Measuring the Effect of Enterprise Architecture

posted Nov 28, 2011, 09:25 AM by Alar Raabe

Some things that can be measured for estimating/following the success of enterprise architecture activities:

Overall trends in enterprise, for which EA should correspond:
- Response time trend for business changes – EA has been successful, if the organization has become more agile.
- Efficiency trend for business operations – EA has been successful, if the organization has become more efficient.
- Reliability trend of business operations and development – EA has been successful, if the amount of failures (both in operation and development) has been reduced.

Special measures for EA value:
- Maintenance of big-picture and reuse of EA information – the ratio of questions related to strategic decisions that can be answered, based on collected and maintained EA information, to the amount of questions that require a special one-time effort (study or project).
- Alignment of activities to business goals (the ratio of projects/solutions that are connected to the business goals, to the total number of projects/solutions).
- The degree of standardization in business – the ratio of different "ways of working" to the overall number of business functions.
- The degree of standardization is IT – ratio of different used IT technologies to the overall number of IT systems.
- The degree of complexity in IT – ratio of supported business functions to the overall number of IT systems.
- The impression of stakeholders, how good/clear is the target ("TO-BE") picture – rating according to some subjective scale.
- The impression of stakeholders, how well complexity is handled – rating according to some subjective scale.

Measures for strength of EA function:
- Strength of architecture governance – ratio of projects/solutions evaluated by architecture board, to the total number of projects/solutions.
- Conformance to the architectural principles – ratio of projects/solutions following the architectural principles to the total number of projects/solutions.
- How well the architecture is followed – ratio of architectural exceptions to the projects/solutions evaluated by architecture board.

About the requirements analysis ...

posted Mar 12, 2011, 09:41 PM by Alar Raabe

Requirements Analysis and Specification
1. Purpose – to understand what is required and to communicate that understanding to other parties.
2. Team
  1. Lead analyst – driving the analysis and requirements process (knowledgeable in analysis and requirements specification techniques).
  2. Domain Experts – bringing the domain knowledge to the analysis and specification process.
  3. Technical Experts – bringing the technical knowledge to the specification process (assuring that the solution which satisfies the stated requirements is feasible).
3. Process
  1. Iterative process, where analysis and specification tasks alternate until the satisfactory requirements specification is produced.
4. Tasks
  1. Requirements Analysis
    1. Purpose – to understand what is required.
    2. Methods
      1. Study of documents – to collect formal information.
      2. Interview of involved parties – to collect informal information.
      3. Workshops – to assure, that all the relevant viewpoints are taken into account.
      4. Modeling and prototyping – to assure, that all the relevant questions are asked.
  2. Requirements Specification
    1. Purpose – to communicate what is required to other parties (developers, testers, ...).
    2. Methods
      1. Writing specification documents – to describe the requirements.
      2. Modeling and prototyping – to assure, that requirements are
        
        unambiguous – all parties understand the same thing,
        
        complete – nothing that is necessary has been left out,
        
        correct – there are no errors,
        
        consistent – there are no contradictions,
        
        verifiable – result can be tested against the requirements,
        
        feasible – result can be achieved,
        
        prioritized – to allow scoping and risk management.
      3. Workshops – to assure, that specifications are correct.
5. Results
  1. Requirements Specification Documents.
  2. Models and prototypes.

Important parts of the business software system (should be defined in the results of requirements specification)
1. Overview – what is the overall purpose and the context (environment) of the system and what are the non-functional requirements (performance, response time, etc.).
2. Data – what information the system maintains (business entities and relationships, their life-cycle and corresponding business rules).
3. Roles – who are the users and what rights they have to perform functions that system provides.
4. Functions – what functions system provides to the users (business processes, business transactions and corresponding business rules).
5. User Interface – what data is presented to and can be entered by the user and what functions are accessible to the user, how the system responds to the user actions.
6. Printouts and reports – what data is collected from the system and how it is presented to the user.
7. External Interfaces – what are the connection points of the system with its environment.

Because every requirement has a price attached (in terms of time and money), they should be handled with care and precision (as money is handled).

About freedom ...

posted Mar 12, 2011, 09:17 PM by Alar Raabe

IT people use Android, but business people use Apple iOS.

Both want freedom, but these are two different freedoms:

IT wants freedom of choice (or freedom to build), but
business wants freedom from choice (or freedom to operate).

The same case is with the agility:

agility for IT is freedom from thinking about business
agility for business is freedom from thinking about IT

What system aspect is above others – who rules in governance ...

posted Mar 03, 2011, 02:35 PM by Alar Raabe

I don’t want to put all the modeling disciplines into the information modeling (as sub-domains) just because most of these are somehow related to information modeling, or just because we can view any modeling activity itself as information processing activity.

For me information modeling is part of the larger domain of modeling the structural aspects of the domains or systems, and answers in this context to the following questions:

What information we capture (represent) about particular domain – here information model should have the connection to the domain model, which itself answers to the question what the domain is and gives the semantics (meaning) to the information model elements.
What information we capture (represent) for a particular purpose – here information model should have the connection to the behavioral models (use-case, process, state-transition, etc. models) of either the domain or the system under study, to show for what and how the information model elements are used.
What are the formal rules for assessing the quality of information (for given purpose) – here information model should have the connection to the domain model constraints for static or structural rules, and connection to the behavioral models for dynamic and context sensitive rules.

It is important to have in mind that because different modeling disciplines cover different aspects of the system under study, we get the full holistic picture only by applying several modeling disciplines, not by putting one discipline above others – real world systems have both structure and behavior at the same time.

That is why I would like to see that neither information owner nor process owner are ruling over each other in information or process governance – the governance should be set over full picture that describes all aspects of given domain or system (EA in case the system is the enterprise).

To achieve the consistency, stability and encapsulation, there is no need to try to establish global governance over all levels, just higher level composition owner should govern the interfaces (incl. both structure and behavior) between the next level components – doing so we are able to partition the models to fight the complexity, and allow freedom of development/governance inside the components.

Business components solve problems of process-orientation

posted Feb 20, 2011, 04:51 PM by Alar Raabe

Most of the problems in process-orientation come from the fact, that processes are viewed as global artifacts independent and above of the functions (business components). Hence for example the problem of cross-functional processes and lack of authority of process owners in the organization.

If we would build the whole enterprise using component-orientation -- that is to encapsulate the processes inside the business components, and allow only interactions of business components based on well-defined interfaces (SLAs), then there will be no such problems, as every process owner is in full control of its processes and resources needed to perform these.

Additionally enterprise would be way more agile (and self-organizing), as responses to the possible changes are localized into the components, any components can be replaced with the best in industry (outsourced) without any adverse effects to business as whole, and the global flows of activities will adjust themselves to the optimal in given context.

If you look from the customer's perspective, then processes are encapsulated inside the component with which you interact.

For example if customer requests for loan offer from sales component, and receives the response from sales component, then it doesn't matter to him/her what other business components are involved and how.

In this case sales component management is completely in charge of the process which is used to produce the response (or service), as it is not crossing borders of component, and component management has SLAs for all the services that it needs/uses from other components -- so there is no need for matrix-organization (with the dual and often conflicting command lines) at all.

To the sales component doesn't actually matter how (using what process) the underwriting is done by the risk management component as long as the SLA for underwriting is not breached.

Software "stack" -- business logic and reusable assets

posted Feb 12, 2011, 11:01 AM by Alar Raabe

Software "stack" -- separation of concerns:

Prerequisite is the traditional architectural layering of application, where:
1. Presentation layer contains only "presentation logic" -- code, that is needed to organize the presentation (mapping) of business information on screen, and to accept and validate the user input from the input devices (e.g. keyboard and mouse). Presentation layer is usually specific to the given user interface device (e.g. web, GUI, mobile phone, ...). As much as possible presentation logic should be declarative (e.g. layout and mappings) or generated.
2. Business Process layer contains "process logic" -- code, that integrates the business functions into business processes, organizes the access to the business rules, and flow of control and information through the business functions. Business process layer manages conversational state and business transactions (sessions). Externalization of process logic and business rules allows easy reconfiguration of business functionality and provides flexibility required by the business. Business rules should be side-effect free and as much as possible declarative.
3. Business Service layer contains "business logic" -- code, that performs transactional business functions or business services, packaged into business service components (usually business functions are grouped around "subject areas" -- e.g. business functions dealing with same business information should be grouped together). Business functions are usually transactional and stateless, they delegate all the state-management and data-intensive functionality to the database layer components. Business service layer could be further divided into two sub-layers: complex business functions and elementary business functions that are reused by the complex business functions to perform their task. Statelessness of business services allows easy scalability by deploying more instances of business service components.
4. Database layer contains "data access/processing logic" -- that is code, that encapsulates access to business data (implements mappings to data store structures), enforces syntactic integrity constraints on business data, and performs or delegates data-intensive business functions to the data store execution engine (stored procedures). As much as possible data access logic should be declarative (e.g. mappings) or generated.
5. Integration layer contains "integration logic" -- that is code, that encapsulates connections to other applications (implements mappings to external data formats, and manages conversational state connected to integration). As much as possible integration logic should be declarative (e.g. mappings) or generated.

All layers could be, if needed, distributed over different processes and/or computers.

(A business function is a function that gives business benefit to the user, it is often specified/described by a business use-case.)

Guidelines for implementing and packaging business logic and reusable assets:

To identify what is the business functionality in given application, following question should be asked: "What remains unchanged, if the user interface and data storage technologies will change?".

As much as possible (when using J2EE platform):
1. All presentation logic should be implemented in presentation layer (using JavaScript/Java or Flex or whatever has chosen).
2. All process logic, management of conversational state, and business rules should be implemented in business process layer (using BPEL/Java).
3. All business functions that do not need large amount of data should be implemented in business service layer as business services (using Java).
4. All business functions that need large amount of data should be implemented in database layer (using stored procedures).
5. All business state should be managed in database.

Interfaces for business functions should (when using J2EE platform):
1. Be defined using Java (and all bindings to other systems (e.g. WSDL/XSD for WS) will be generated from the service interface definitions),
2. Should be coarse-grained to avoid latency problems related to the remote access,
3. Conform to rules for remotable interfaces (take into account that methods could be called remotely),
4. Always have a service context (representing business context, time context and technical context) as a required input/output argument of every method (this could be used for carrying conversational state is such need will arise -- e.g. partitioning result of a method that returns large amount of data),
5. Contain extension points that could be used to extend/customize the business function (without changing the public interface of business function),
6. Use synthetic technical IDs or keys (which should not containing business data) to represent identities of business objects in the interface (such IDs should be considered temporary -- e.g. users of business functions should not rely that they are same in successive uses of given business function),
7. Use return values for communicating business exceptions,
8. Use Java exceptions only for technical exceptions.
9. Be documented according to the JavaDoc best practices, so that for every method in the service interface following is described:
  1. The business function performed ("what"),
  2. The meaning of input and output parameters,
  3. The meaning of technical exceptions,
  4. The purpose and usage of the method illustrated with examples.

Business service components should have following interfaces:
1. Business service interfaces, through which all business functions that given business service component offers, could be accessed.
  If needed business service should have two separate business service interfaces with different granularity to be used for different situations:
  1. Fine-grained interface (where single transaction requires small amount of data and provides small piece of business functionality) for local usage where transport mechanism provides low-latency connection to the service component, and
  2. Coarse-grained interface (where single transaction requires large amount of data and provides large piece of business functionality) for remote usage where transport mechanism provides high-latency connection to the service component.
2. Configuration interface, through which the variability offered by the business service component is configured (usually during setup/startup process).
3. Management interface, through which service component could be identified (for configuration identification) and managed during run-time.
4. Service provider interfaces for other business or supporting services that given business service component requires for performing its functions

Reusable assets should be treated same way as third-party products:
1. Reusable assets should have:
  1. Dedicated development team.
  2. Its own development goals, roadmap (together with a process for collecting feature requests), and release cycle (changes to the public interfaces should be done through deprecation and phase-off cycle).
  3. A support service (together with a process for reacting to the defect reports and releasing fix-packs).
2. Reusable asset should be isolated from the "client code" by isolation and customization layer.
3. Package of reusable asset should contain:
  1. Release notes.
  2. Developer's package:
    1. Programmer's Guide;
    2. Programmer's Reference;
    3. Installation scripts and database scripts (creation and upgrade);
    4. Interface definitions;
    5. Development binaries (if such are different from production binaries) and parameter files;
    6. Source code for debugging purposes;
    7. Development dependencies (if such are different from production dependencies);
    8. Usage (and customization) example(s) with the build scripts.
  3. Operational package:
    1. Installation and Configuration Guide;
    2. Operation and Administration Guide;
    3. Installation scripts and database scripts (creation and upgrade);
    4. Production binaries and parameter files;
    5. Production dependencies.

How to start describing business (architecture)

posted Feb 09, 2011, 09:46 PM by Alar Raabe

Use IBM's CBM method and generic industry CBM to identify the business components (business functions) -- identify three cases for components:
1. that match fully (exist in generic industry CBM),
2. that match partially, and
3. are missing from generic industry CBM.
Map the resulting business components to the existing organizational structure (verify this mapping with the responsibility descriptions of organizational units)
Define the external boundary (interface) of business system(s) – identify:
1. the service types delivered/produced and
2. the service types required/consumed to both external and internal customers.
Map the resulting service types to the business components.
Consolidate/split business components (business functions) not depending on the existing organizational structure, but depending on the coupling between components (functions).
Define the used/planned business model(s) by defining (according to Osterwalder's method):
1. customer segments (types)
2. channels
3. value offerings (products) -- packages of the predefined services deliverable to the customer segments
Delivered service types on the external boundary (interface) identify the primary business processes, needed to produce services.
If primary business processes are identified, then describe these on very high level -- not yet even the diagram of activities, but inputs, outputs, performers, material resources used/needed, purpose, dependencies, etc. (for example using SIPOC).
Supporting business processes could be then identified from:
1. the (human and material) resources needed for primary processes -- resources need to be managed, and
2. the primary and supporting business processes themselves -- processes also need to be managed (planning and controlling).

Specifications and actuals (and UML powertypes)

posted Feb 09, 2011, 09:43 PM by Alar Raabe

What I have in mind, is the duality of concepts in the domain, where:

some concepts refer to the actual things/objects (like product, property, …), and
other concepts refer to different things/objects, which are specifications (or descriptions) for the previous ones (like product specification, property description, …).

Both sets of concepts being on the same modeling level, and always have at least one-to-many relationships between each other. The difference of specification from the actual is, that specification can, and in many cases do exist without corresponding actuals. Also specifications have usually own behavior, which is different from behavior of actual.

Participants of this (pattern?) could be represented in models using corresponding stereotypes, or just grouping these together on diagrams.

This pattern has helped me to identify concepts/relationships, and to organize the model.

Maybe this would be possible to model using UML powertypes, but I would avoid mixing different modeling levels (model, meta-model, ...) in the same model, and would prefer to use stereotypes instead of these (to show that certain classes are from given class denoted by stereotype).

If we want to model the business rules for meta-model elements, then we should have a separate meta-model, that shows the specialized elements and respective rules/constraints attached to these.

This distinction in modeling levels is good to be maintained also into the solution, down to the physical models -- that is if we choose to have dynamically configurable system, then from the meta-models we derive the physical models representing the configuration information, and from the models we derive the actual content of configuration information for the system. Failure to make this distinction clearly is the source of problems in maintenance of dynamically configurable systems.

What Fowler describes as specification pattern seems to me too narrowly applied only for selecting objects from object sets, but maybe I am mistaken.

On EA function and the "customer" of EA

posted Feb 04, 2011, 09:53 PM by Alar Raabe

Gartner Pub. "Develop Next-State Enterprise Architecture to Improve Usability" states: "Too many EA programs are suffering because their content is being largely ignored by some of the very people they are trying to serve -- project teams."

Is it really so that EA program is trying to or must serve project teams?

I would argue, that the main purpose of the EA programs is not to serve, but to constraint the project teams -- doing so of course in the name of serving the whole enterprise including the project teams, but still the main purpose is to impose the constraints that restrict the project teams.

It is the same, as police is establishing speed limits for motorists -- for benefit of whole society some of the members need to be restricted in their doings.

This of course doesn't mean, that restrictions/constraints developed by EA program, doesn't have to be "actionable" and "pragmatic".

The detail level and overall nature of restrictions/constraints has to match the maturity of project teams -- by analogy, for small children the restrictions must be very precise and categorical, but when dealing with grown-ups you can rely on some level of common sense (or maybe not).<7p>

...

The overall question is about the primary stakeholder/counter-party -- who EA function serves.

Does the EA function serve management in development of enterprise, working for global goals, or does it serve the project teams, working for local goals? I would focus more on serving the management and global goals, because project teams are already served by the application architects.

There was an important remainder in the article -- you can't have road map (next steps), before you have future state!