Modularizing your Business and Software Component Design

In this blog, I will talk about modularizing your enterprise from a business and software perspective. We start from the business perspective, where I provide some background how today’s businesses are modularized. Afterwards, we will investigate how we can support the modularized business with software components and how they can be designed. Finally, we will see some software tools enabling component-based design for a modularized business, such as the service component architecture (SCA) or OSGi.

Business perspective

You will find a lot of different definitions of what and how a business can be modularized. Most commonly, business modules are known as business functions, such as controlling, finance, marketing, sales or production. Of course you can view this also on a more fine granular level. Furthermore, we may have several instances of the same module. This is illustrated in the following figure. On the left-hand side the business modules of a single enterprise are shown. On the right-hand side you see the business modules of decentralized organizations. There, the enterprise is split up in several enterprises, one for each region. Business modules are replicated across regions, but adapted to local needs.


A module has usually clear interfaces to other modules. For instance, in earlier times you used paper forms to order something from the production department.

One of the most interesting questions is how one should design business modules. Well there is no easy answer to this, but one goal is to reduce complexity between modules. This means there should not be many dependencies between modules, if any. There can be a lot of dependencies within one module. For instance, people work very closely together in the production department, because they share common knowledge and resources, such as machines or financial ones.

On the other side, production and sales have some very different business processes. Obviously, they are still dependent, but this should be done through a clear interface between them. For example, there can be regular feedback from a sales person to the production engineer on what the customer needs.

Clearly, it depends on the economic environment how you define business modules and the organization. However, this environment changes and this means business modules can be retired, new interfaces or completely new business modules be created.

Unfortunately, this is usually not very well documented and communicated in many businesses. Particularly, the conditions why a business has been designed out of a given set of modules and dependencies exists usually only in the head of some people. Additionally, the interfaces between business modules and their purpose are often not obvious. This can mean significant loss of competitive advantages.

Linking Business and IT Perspective: Enterprise Architecture

Business and IT have not necessarily the same goals. This means they need to be aligned, so that they are not conflicting. Hence, you need to map your business modules to your IT components. This process is called Enterprise Architecture Management. During this process the Enterprise Architecture is constantly modified and adapted to the economic environment.

Of course, you cannot map all your business and your whole IT, because this would be too costly. Nevertheless, you need to choose the important parts that you want to map. Additionally, you will need to define governance processes and structures related to this, but this is not part of this blog entry.

One popular, but simple, illustration is an enterprise architecture composed of four architectures:

  • The Business Architecture describes the business functions/modules, their relations within business processes, people, the underlying strategy, business goals and the relevant economic environment.
  • The Information Architecture is about the business data, their relationships to business functions/modules and processes, the people, its value as well as security concerns.
  • The Software Architecture depicts different kind of components according to IT goals, their relations to business data and business functions/modules.
  • The Technology Architecture is about the technology foundation for enabling the other architectures. It describes the basic infrastructure in form of hardware and software components. This includes local environments as well as cloud environments, such as OpenStack, Google Compute or Amazon EC2.

Some people advocate additionally an IT security architecture. I propose to model it not as an additional architecture, but include IT security concerns in each of the aforementioned architectures. This increases the awareness for IT security in your business. Nevertheless, appropriate tools can generate from the models a complete security view over all architectures.

There are many popular tools, such as the ARIS toolset to map your enterprise architecture.

Of course, you cannot only define top-down from business to IT how this architecture should be designed. You need to take into account the IT perspective.

IT perspective

As mentioned, IT and business goals are not necessarily the same. IT focuses on three areas: storing of information (storage), processing of information (computation) and transporting information (network). The goal is to do this in an efficient manner: Only the minimum of information should be stored, processing information should be as fast as possible and transporting information should only consume minimal resources. Clearly, there are constraints ranging from physical laws over business goals to IT Security concerns. For instance, the three key IT Security goals, namely confidentiality, integrity and availability often have negative impact on all three IT goals.

As I have explained before: business modules are mapped to software components and vice versa. One big question here is about the design of software components, i.e. what software functionality (representing business functionality) should be part of one software component and not one of the others. Software components are usually different from the business modules, because they have different design criteria.

In the past, people often used heuristics. E.g. they introduce “data components” and “functional components”. This makes sense, because you should not have 50 different databases, but only the right amount of databases for your purpose (e.g. one for NoSQL, one for SQL and/or probabilistic databases). This reduces the resource needs and avoids inconsistent data. However, there is no general approach how these heuristics should be applied by different enterprise architects. Another problem is that communication patterns (e.g. via message brokers, such as RabbitMQ) are completely left out.

Hence, I think a more scientific or general approach should be taken towards the design of components, because these heuristics do not give you good guidelines for a sustainable architecture. Based on the three IT focus areas, I propose to have software components for storage (e.g. database), computation (e.g. business logic) and network (e.g. message brokers). Once you have identified these components, you need to decide which functionality you should put in which component. One key goal should be to reduce the dependencies between components. The more communication you have, the more dependencies you have between the different functions in components. Evaluating this manually can be costly and error prone. Luckily, some approaches do this for your and they can be integrated with business modeling as well as software component management tools (cf. here an approach that derives the design of software components (managed using the service component architecture (SCA)) from the communication pattern in business processed (modeled using the business process modeling notation (BPMN)).

Another mean for coherent software component design is to have enterprise architects responsible for mapping one part of the business (e.g. controlling) reviewing the software architecture for another part of the business (e.g. marketing). I introduced such a process in an enterprise some time ago. Such an approach ensures that architecture decisions are made consistent across the enterprise architecture and this fosters also learning from other areas.

Finally, a key problem that you need to consider is the lifecycle management of a software component. Similar to the lifecycle of business modules, software components are designed, implemented, deployed and eventually retired. You need tools to appropriately manage software components.

Tools for Managing Software Components

Previously, I elaborated on the requirements for managing software components:

  • Handle interfaces with other components

  • Support the lifecycle of software components

Two known information technologies for managing software components are OSGi and the Service Component Architecture (SCA).


OSGi is a framework for managing software components and their dependencies/interfaces to other components. It is developed by the OSGi alliance. It origins from the Java world and is mostly suitable for Java components, although it has limited support for other non-Java platforms. It considers the lifecycle of components by ensuring that all needed components are started when a component is started and by being able to stop components during runtime. Furthermore, other components and their interfaces can be discovered at runtime. However, there is no deployment method for software components part of the standard.

Since Java can run on many different devices, it is available for Android, iOS, embedded devices, personal computers and servers.

Unfortunately, tool support for linking OSGi and business or information architecture is very limited. Furthermore, an automatic generation and deployment of OSGi components from your enterprise architecture does not exist at the moment. This makes it difficult to understand software component and their relations within your enterprise architecture.

Many popular software projects are based on OSGi, such as the Eclipse project.

Service Component Architecture (SCA)

The service component architecture is a specification for describing software components, their interfaces and their dependencies. It is developed by members of the Organization for the Advancement of Structured Information Standards (OASIS). It does not depend on a specific programming platform, e.g. it supports Java and C++. It supports policies that govern components, a set of components or their communication. However, SCA does not consider the software component lifecycle or how they are deployed exactly.

It is supported by many middleware frameworks, such as TIBCO Active Matrix or Oracle Fusion Middleware.

Similarly to OSGi there is little tool support for linking SCA components and the business or information architecture. However, the SCA specification has a graphical modeling guideline and some recent work describes how they can be linked via business processes. Since OASIS is responsible for other enterprise architecture relevant modeling notations (e.g. BPMN), it can be expected that enterprise architecture tools can be adapted to provide support for linking different parts of the enterprise architecture.


Modularizing your business and designing software component is a difficult task. Not many people understand the whole chain from business to software components. While enterprise architecture and modeling has become a popular topic in research and practice, the whole tool chain from business to software components is not. There have been attempts to introduce model-driven-architecture (MDA), but the supported models were mostly only restricted to the Unified-Modeling-Language, which is not very suitable for business modeling and can be very complex. Additionally it does not take into account the software component lifecycle. Furthermore, the roles of the different stakeholders (e.g. business and IT) using these tools are unclear.

Nevertheless, new approaches based on the business process modeling notation and frameworks for managing software components make me confident that this will change in the near future. Growing IT complexity in terms of communication and virtualization infrastructure will require software support for managing software components. Companies should embrace these new tools to gain competitive advantages in terms of agility and flexibility.

The Emergence of Rule Management Systems for End Users

Long envisioned in research and industry, they have silently emerged: rule management systems for end users to manage their personal (business) processes. End users use these systems to define rules that automate parts of their daily behavior to have more time for their life. I will explain in this blog entry new trends and challenges as well as business opportunities.

What is it about?

Our life is full of decisions. Let it be complex unique decisions, but also simple reoccurring ones, such as switching off the energy at home when we leave it or sending a message to your family that you left work. Another more recent example is taking a picture and uploading it automatically to Facebook and Twitter. Making and executing simple decisions take our time, which could be used for something more important. Hence, we wish to automate them as much as possible.

The idea is not new. More technical interested people have used computers or home automation systems since several years or even decades. However, they required a lot of time to learn them, complex to configure / required software engineering skills, were proprietary and it was very uncertain if the manufacturer will still support them in a few years.

This has changed. Technology is part of everybody’s life, especially since the smartphone and cloud boom. We use apps for our smartphone or as part of the cloud that help us automating our life and I will present in the following two apps in this area. These apps can be used by anyone and not only software engineers.

What products exist?


The first app that I am going to present is a cloud-based app called ifttt (if this then that), which has been created by a startup company. You can use a graphical tool to describe rules for integrating various cloud services, such as Facebook, Dropbox, Foursquare, Google Calendar, Stocks or Weather. These cloud services are called channels in ifttt.

A rule has the simple format “if this then that”. The “this” part refers to triggers that start actions specified by the “that” part. The ifttt application polls the channels every 15 minutes if they have any new data and evaluates if new data triggers actions specified in the “that” part.

Defining rules is an easy task, but a user does not necessarily have to do this. A huge community has already created a lot of so-called recipes, which are predefined rules that can be just used by any other user without any effort. Examples for these recipes are:


On(X) is a mobile and cloud application created by Microsoft Research. It leverages sensor information of your mobile for evaluating rules and triggering actions. Contrary to the aforementioned app it is thus not limited to data from other cloud platforms.

Rules are described using a JavaScript language (find some examples here). This means end users cannot use a graphical tool and have to have some scripting language knowledge. Luckily, the platform offers also some receipts:

We see that the receipts are more sophisticated, because they can leverage sensor information of the mobile (location/geofencing or movement).

What is in for business?

Using these personal rule engines for business purposes is an unexplored topic. I expect that they could lead to more efficiency and new business models. For example, consider the following business model:

Furthermore, we can envision improved service quality by using personal rule engines in various domains

  • Medicine: if user is in the kitchen then remind to take medicine, if it has not been taken yet for the day
  • Energy saving: If I leave my house then shut down all energy consumers except the heater.
  • Food delivery: If I am within 10 km range of my destination then start delivering the pizza I have ordered
  • Car sharing: If I leave work send a SMS to all my colleagues I share my car with
  • Team collaboration: We can evaluate if team members or members of different teams want to do the same actions or waiting for similar triggers. They can be brought together based on their defined rules to improve or split their work more efficiently.

Future research

The aforementioned applications are prototypes. They need to be enhanced and business models need to be defined for them. First of all, we need to be clear about what we want to achieve with automating simple decisions, e.g.

    • Cost savings
    • Categorizing for quicker finding and publishing information
    • Socializing

An important research direction is how we could mine the rules, e.g. for offering advertisement or bringing people together. Most of the mining algorithms to day focus on mining unstructured or unrelated data, but how can we mine rules of different users and make sense out of them?

Another technical problem is the time between rule evaluation and execution. For instance, ifttt only polls every 15 minutes its data sources to check if actions in a rule should be triggered. This can be too late in time critical situations or can lead to confusing actions.

From a business point of view, it would be interesting to investigate the integration of personal rule management into Enterprise Resource Planning (ERP) systems as well as to provide a social platform to optimize and share rules.

Finally, I think it is important to think about rules involving or affecting several persons. For example, let us assume that a user “A” defined the rule “when I leave work then inform my car sharing colleagues”. One of the car sharing colleagues has the rule “when a user informs me about car sharing then inform all others that I do need a seat in a car anymore”. If user “A” now cannot bring the car sharing colleague home then he or she has a problem.

A more simpler example would be if user “A” defines a rule “If user ‘B’ sends me a message then send him a message back” and user ‘B’ defines a rule “If user ‘A’ sends me a message then send him a message back”. This would lead to an indefinite message exchange between the users.

Here we need to be able to identify and handle conflicts.

OData – The Evolution of REST


Making the data, hidden in various cloud platforms, available and understandable so that it can be processed by software services as well as human beings is one of the key challenges. Tim Berners-Lee coined this challenge “Linked Data”. However, he remained rather vague on how this data should be linked technically. An initiative of major software vendors, such as Citrix, IBM, Microsoft, Progress Software, SAP and WSO2, addressed this problem by proposing the Open Data Protocol (OData) standard to the Organization for the Advancement of Structured Information Standards (OASIS). All kind of software can leverage OData, but it is particularly interesting for business software, such as business process management systems, business rule systems and complex event processing middleware. OData can be seen as the technical foundation for open data, which comprises initiatives from various governments and organizations to make data publicly available.


OData is inspired by the Representation State Transfer (REST) approach. Basically, REST is about clients creating, accessing, deleting or modifying resources, identified by Unique Resource Identifiers (URI), from the server. A resource can represent any concept in form of any data structure. Data structures can be described in a plethora of formats, such as the JavaScript Object Notation (JSON) or the eXtended Markup Language (XML). REST was becoming more and more popular with the emergence of complex web applications using HTML5 and Javascript.

Although not limited to any specific protocol between clients and servers, REST has been originally described and is now mostly implemented using the Hyper Text Transfer Protocol (HTTP). This allows creating, modifying, deleting or reading resources. Furthermore, we can create more sophisticated Internet based architectures for managing the data (e.g. proxies or IT security concepts).

Example (REST) We assume that a client (C) communicates with the server (S) using HTTP. The client requests the data of a book identified by the following URI: The server answers with basic book data using the JSON format. The protocol can be described as follows:

(C) Request:


(S) Response:

HTTP/1.1 200 OK


“title”: “Kritik der praktischen Vernunft”,

„author“: „Immanuel Kant“,

„year“: „1788/2003“


Similarly, we can create, modify or delete resources.


It has been shown that REST provides a lot of flexibility for managing data over the Internet. This can be seen from the plethora of web applications using it. However, it has some limitations. For example, we can only do simple data update or retrieval operation via the URI, but we cannot articulate more complex queries in our web application or for representing media streams. An example for a complex query is the following (using OData notation):$filter=Revenue gt 1000.00

This query asks for all the customers with revenue greater than 1000.00 Euro. The query can be executed similarly to the REST example presented before.

OData standardizes a wide range of different queries on the service level, which makes it very easy to reuse Odata services or do add enhanced flexibility/agility to your business processes.

Of course, we can use this query language also to update or delete resources.


Selected OData Concepts

OData can leverage and extend the Atom Syndication format or the Atom Publishing Protocol. You probably know these standards from web feeds (e.g. news) in your browser. They basically describe semantics for news, such as headlines, pictures or full-text. These standards can be used to represent answers to queries containing more than one entity (e.g. multiple customer records).

OData services can articulate what data they understand and produce. Clients can use this information to compose one or more OData services to fulfill their intents. For example, OData services are described using the metadata document and the service document. The first one is conceptually similar to the Web Service Description Language (WSDL). It describes operations and data provided by the OData service. The service document describes a set of entity collections that can be queried from the services. For instance, all customers that have a pay-tv subscription.

Unfortunately, it is not clear if OData is supposed to support queries requiring constructing a transitive closure. These type of queries are, for instance, useful to retrieve all the indirect flights between two airports. It may be supported by OData functions or on the client side, but not as part of the standard.

Conclusion and Outlook

OData has a lot of benefits. It leverages well proven internet concepts. HTML5 web applications can immediately start using it without changes to existing browsers. Finally, it has support by major vendors for business software.

There have been some competing proposals for managing data over the internet, such as GData by Google, but they seem to be deprecated by now.

However, some elements are missing in the OData proposal. For example, it is difficult to describe temporal queries, such as “Provide me all activities that have finished at the same time in the production process”. A lot of research has been done on representing temporal data in information systems (e.g. I used it to provide information system support for managing highly dynamic processes in the crisis response). Thus, I think this would be a beneficial feature. In fact, there have been proposals for extending the OData standard with temporal data. However, they remain rather simple and would not allow dealing with qualitative temporal queries (“finish at the same time”) as I have described before.

The same holds for geospatial queries. An example for a geospatial query is “Provide me all the warehouses in the disaster affected area”. Luckily, we have also here some proposals to extend the OData standard to support these types of queries.

What is next?

We have a lot of redundant and related data provided by different organizations. OData is focusing on single data sources and at the moment it is unclear how to relate and integrate many different sources from different information providers. This is mostly a semantic problem. For instance, a manager can be described as a director in different companies and vice versa. A solution could be to agree on OData Metadata documents to define semantics. This has to be done by domain experts as it had occurred in the area of reference models, such as the one I explained before about humanitarian supply chain management (cf. also the Humanitarian eXchange Language). Finally, we may use translation languages, such as XSLT to automate integration of semantically different information.

Further references