Do we need Archimate?

A recent, provocative, post on linkedin, posed some issues about the Archimate standard.

One of my first doubts, using introducing Archimate in our Architecture Capability, was: “why was it created as a separate graphical language and not as an UML profile?”. This doubt is still in my mind, in my previous post about this topic, I have inserted some links about this argument. The “UML profile” solution appears as natural, because a lot of classifiers from UML are available – with the same semantic and graphical notation – also in Archimate.

What are the consequences of a “separate” graphical model?

(+) dedicated modeling tools

(-) multiple skills/tools/repositories

(-) requirements for model integration

On the other side, I think that we should remember that Archimate and UML have different “meanings”:

  • Archimate is for architecture,
  • UML is for engineering.

Also if you look at building design, you will find an “Architectural” project, showing you the shape, internal space allocation, external appearance, of the building, and several specialized views (structural project, electrical plant, elevators, etc.); perhaps the potential buyer of the house is not interested in how many cables or switches are necessary to operate the elevator – and could not understand this view – but is interested in the size and number of windows of the living room.

Despite this, I believe that “Archimate as UML profile” could bear the same expressiveness, the same semantic content, and a seamless integration of architectural and technical layers.

a building under construction

Personally, I am evaluating the introduction of Archimate, and starting to represent (maybe with better results) our architecture with this language. But, in the mean time, and waiting for the similar OMG work, I am starting do develop an UML profile with the same content of Archimate. At this point, we are working on the Business Layer. The modeling tool that we use, by Sparx Systems, allows for an easy integration on different models using UML, BPMN or Archimate, so it does not force the user to a specific adoption profile. But, in the meantime, the UML-profile approach is allowing us to obtain stakeholder-oriented documentation with a better quality, and an easier transition from the previous graphical representation standards.

At the same time, the introduction of Archimate shows its usefulness in a more formalized and rigorous architectural design practice, relaying on a number of elements that fits well with the various organizational patterns that exists in our Company.

The results – at this point – are promising, I will share them later, and introduce some of them in the second edition on my book about BPMN.

Bottom line: I believe that we need archimate, as a component of our architecture capability. Maybe, representing it as an UML profile could help its adoption.

Advertisements

Hacking the value of integration

During the last two years, in my company, we have started a series of projects to enhance our SAP ECC platform, in the direction of business integration across the software modules.

This happened because we have spotted some limits in the architecture of this ERP system. SAP is a well-integrated software suite, in his main areas (Financial, Logistics, Sales, Real Estate, HR, etc.) it offers a bulk set of functions, that cover the typical business processes in a very wide set of industries. So, where are these limits?

I will try to suggest some ideas and discussion topics across the posts of this blog.

My company operates in the Construction and Real Estate industry. Our business processes start from the acquisition and development of lands, until the sale of residential properties or the management of commercial properties that are leased out. SAP ECC was installed in late 2005, replacing a previous Italian ERP solution. Initially, SAP was not a successful project. Since 2008, we have started a complete re-engineering of SAP implementation, changing the design from a module/office centric design to a business-centric design.

Let’s start now from a small development that we are carrying on now: cash management by an economic business perspective.

We have a very basic configuration of the CM module: bank and cash accounts, customers and suppliers accounts, are classified according to categories that are relevant for our business. With these settings, we are able to perform a basic analysis of financial flows; this is important, because our business relies heavily on the financial supplies from banks, and our finance dept. needs to monitor the cash levels versus the financial planning.

Unfortunately, the simple analysis of bank accounts doesn’t allow us to understand how the sources and destinations of liquidity have influenced their balances. So we need to drill down this analysis across our business units, and across the development projects that are active.

A good perspective of our business is given by the Profit Center hierarchy: it is roughly divided in the following areas:

  • commercial real estate
  • residential real estate
  • property development
  • operating expenses
  • corporate finance

Each area is divided according to the management perspective of the underlying business: residential real estate, as an example, is detailed at building level; several buildings are grouped together according to the land on which they are built.

We are simply building a set of reports that allows our financial analysts to separate incoming and outgoing cash flows according to the building, building part, or single controlling-relevant business element that originates the costs or incomes from which the income or payment comes.

The key of those reports is a function that, given a cash management relevant posting, goes back to the invoice or other FI document, with a controlling destination, that is paid or collected.

I will discuss in some following posts why this solution fits our needs. The point now is the importance to link one area of the ECC system – Controlling – with another area – cash flows analysis, giving the financial analyst a perspective that is the same shared by the financial planners, the production manager, etc.