Introducing Information Management for NoSQL

As Gartner warns in the report, adopting NoSQL storage can result in Information … read more

Introducing Quantitative Enterprise Architecture

It is rather ridiculous that the discussion on Data Driven Enterprise did not … read more

OWL Modelling for Information Architects

Business Abstraction delivered OWL training customised for experienced Information Architects. The target audience … read more

Business Component Modelling

Business Component Modelling was created to enable Business Architects with some IT/Development background to define Business Services, enable and validate Business Agility,. It provides an effective framework for SOA implementation and maintenance.


It’s been universally recognized, in principle, that “SOA is a business agility strategy”, however for the last decade enterprises were investing heavily into implementing rather expensive SOA technology. Now, when either the technology is implemented, or the enterprise successfully sat on the fence waiting for others to prove the case, perhaps we should find out how SOAP & REST  interfaces, service middleware, content-based routing and process-execution engines are related to this magical Business Agility.

The vision of SOA is of individual applications easily connected and reconnected to create new product and improve Business Processes, as well as to engage external vendors ind partners in seamless way.  SOA technology allows us to do connection and re-connection easier than before. However that technical ability to connect means little unless someone can figure out what to connect to what, and the result is likely to work, which require:

  • Interfaces should be well understood, and their number should be kept manageable – just eh sum of all APIs of all systems installed in the enterprise won’t do, they are too many to handle.
  • Interfaces should be understood by the business, as they are the people who should be directly involved in the process.
  • Interfaces should be precisely defined and comprehensively tested, so using an interface should not require re-testing of all involved systems.
  • To satisfy the above, the interface should provide an access to a Business Service encapsulating computational capabilities, data storage and even human roles, thus ensuring that inter-dependent interfaces can be isolated.
Overall the task of designing effective and testable Business Services sounds very much like Object Design and later Component Design, only on much higher level. We used this analogy to develop Business Component Modelling so  Business Architects with some Development background can effectively design and validate Business Services for Business Agility.


Business Component Modelling While Paper

Business Component Modelling Process Definition

Example: Unified Courier Service