There is a lot of attention, in the software development industry, upon software reuse. It’s a good practice, also if, often, reusing “old” software, may be a compromise solution.

Now, I want to share my ideas about “reusing” user interfaces.

In my Company, we manage an ERP system. Our business architecture is quite complex, and several processes are managed with the ERP system. System users are mainly “expert” users, people who post transactions, interact with the system, during all the workday.

There is also a set of “non-expert” users: field technicians, managers, salespeople. These people follow different interaction paths: they require information, but are not aware of “codes”, “transactions”, “modules”. At the same time they should interact with the system, but only in a limited way: an approval, a feedback, etc.

Asking them to login to the system, learn how it works, its internal logic, may be hard. At the same time, each user may consume a “seat licence”. This means additional licensing and maintenance fees.

There are many solutions for this common issue: enterprise portals, or web based applications (for purchase requisitions approval, time sheets, service reports,and so on).

But, still, all these apps require that the user adopt a new “channel” to interact with the system. This means a user interface, application logic, etc. With the term “channel”, I mean the aggregate of user interface and human machine interaction paths, or execution environment. Every time that a user has to “switch” from a channel to another (consider leaving your email client and opening a spreadsheet), he will spend an amount of mental energy only because the environment changes, and his brain have to “recall” the knowledge about the new channel. This amount of energy increases if the new channel is used with much less frequency than the previous one; eventually this may cause a “rejection” of the second channel.

We tried something simple, nothing new, but a comprehensive approach, leveraging the opportunities offered by an integrated cloud service. We tried to use a number of well known “channels”, like email and intranet, to deliver some simple interactions with our ERP system.

Today, quite every business operate some basic services to support collaboration:

 

  • Email
  • File sharing
  • An intranet

 

Every user is able to interact with these systems.

My Company have migrated, few years ago, those services on a cloud platform, a project that I have managed. It was a good move; anyhow you may find a lot of documents and discussions about this kind of solutions, googling around.

But the key advantage of an integrated, cloud-based, collaboration services solution, is search.

The search engine paradigm is one of the easiest pattern for user interface: you need something, you type in a box what you need, the system returns a list of results. You can browse through results, searching what you need, and, eventually, finding something useful that you weren’t aware of.

Al, happens in a fraction of a second. Cloud-based search engines are really powerful.

I have imagined that leveraging this feature, and using the email as a “transactional” interface, may lower the ERP adoption barrier for “non-expert” users.

So, we started to architect and develop some simple software modules, following three main patterns:

  • Publish: a report, as a document or web page;
  • Push: notification about transactions posted, or status changes;
  • Ask confirmations, approvals, or information.

 

For the first pattern, we used document sharing or intranet; for the other two, email, or web-based forms in some cases.

For example, if a mall manager wants to open a purchasing request, he uses a web form. The systems then creates a shared folder, that will be used to store RFP, Vendor offerings, budget status reports, and all the documents required for the approval process.

The organizational units involved will receive an email, with the notice of the new request. The central purchasing administration office will create a request in the ERP system, linking it with the shared folder.

The ERP system will start publishing some documents, about the request, in the shared folder: budget status, potential vendors list, etc.

Just imagine. Users not directly involved with data entry and transactions on the ERP system are able to find all the information, searching their inbox, or their file collection. They may not be aware that an ERP system is working behind the scenes. All the documents are linked together, just as usual for web pages. The search engine can be used to find everything, typing the name of the vendor, or a project description, or a tenant name.

 

We have applied this approach to several processes. The final result is that a user can simply search his mail/file/intranet archive, freely, typing just few keywords, and find what he needs.

The training required was near to zero.

 

Now, few notes for the techies.

Creating a communication link between an ERP server buried in a closed, protected, subnetwork, and a cloud service (which usually is protected in an insane way) is not easy.

Luckily our requirements weren’t so strict, no “real-time” interaction was required.

We built our interface on two widely used standards: SMTP and JSON. They are not specific of any platform,  they are vendor neutral,  and well supported on both our subsystems. So:

  • Direct email from the ERP to the user inbox for notifications and requests;
  • Structured data in a JSON document enclosed in a email for publishing.

 

Some scripts running on the cloud platform do the processing required for publishing the data embedded in JSON files. We developed a simple template engine, to speed up the graphical/layout design phase.

In this way we are able to manage the ERP-to-cloud channel.

Figura per post mail ERP integration_02

To get back Data, from the cloud, toward the ERP, we still use an email,  with some control codes embedded in it,  delegating to a small java application the task of retrieving mail messages, parsing their content, and performing a remote function call on the ERP (this can be developed directly within the ERP platform, but our current release doesn’t support the required APIs). Open source tools like Gradle and Maven provided a convenient support for packaging the runtime artifacts and retrieve/align the required libraries.

Developing everything was quite easy: both systems provide simple conversions from/to JSON. Both systems have a development environment supporting interfaces for email sending/processing. Both systems have templating engines, critical to achieve “presentation” components that are easy to maintain.

 

With this approach, we have a certain degree of independence from each of the connected subsystems.

Clearly, we have used a specific ERP and a specific cloud solution, but I don’t want to make reference to a single product, because this kind of approach can be easily followed using any of the main products available in each segment. All the “my product is clearly the best” marketing claims overestimate the differences existing among different architectures. I think that a professional ERP manager or solution architect can obtain quite the same result working on any platform.

Do we need Archimate?

September 2, 2015

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.

Representing organizational structures, roles, responsibilities, and linking this model with the process model, could be a mess, especially if your Architecture model should integrate perspectives modeled according to different standards.

I expose here some ideas that we are putting in practice across our Enterprise Architecture projects, in my current Company.

The topic of model mapping is hot: you can find a lot of interesting toughts in the blogs of Gerben Weirda. At the same time, the OMG is working on a UML profile for Archimate.

I will start with Archimate, and the basic elements from the Business Layer: Actor and Role.

The following picture, shows a suggested extension:

Archimate extension roleactor

The Role is specialized, leading to four different stereotypes:

  1. Organizational role: a role that is specific of an organizational unit, eg. Director (role) of IT (unit).
  2. Functional role: a role that is specific of a function or authority assigned to a person, eg. Sales Representative.
  3. Process role: a role that has a meaning in the context of one or more processes, eg. “Purchasing requester”, “credit approver”
  4. Partner role: a role of an external partner in a collaboration, eg. Customer, Bank, Tax agency.

At the same time, the Actor element is specialized:

  1. Organization unit: an element of the organization which may be aggregated at an higher level, or may aggregate lower level units. The dependency may follow several patterns: hierarchical, matrix.
  2. Human Business Actor: a single, identified person.
  3. External partner: a person or organization external from our business.

The diagram shows the main relationships among elements. The “Process role” may be assigned to a human actor, another functional or organizational role. Anyhow, it is meaningful only n he context of execution of a single instance of one or more processes,

Why do we need those extensions? Well, mainly for ease of communication with some stakeholders. It is common wisdom that complexity in the metamodel leads to obscure resulting models (for the eyes of non-professional stakeholders). But in this case, I think that a little bit of specialization is useful:

  • specialization of user roles helps the overall classification of them, and provide some guidance also for junior analysts and people outside the Architecture practice.
  • Specialization of business actors helps avoiding the potential ambiguity deriving from the fact that a branch, an office, a bank, or a receptionist are all modeled with the same element.

In the following posts, I will describe how we have translated this profile in UML, and how we have linked the Business Layer with the relevant elements of BPMN models.

Every business deals with a finite number of entities, concepts, things, as you may prefer to name them.

Every modeling standard and project framework deals with this, approaching this description from several different viewpoints.

The existence of different descriptions, at different abstraction levels, for the same thing, and the logical links between these different modeling contexts, is one key output of an Enterprise Architecture capability.

Let’s look at the following picture, showing a common concept, “Vendor”, at different architecture layers.

Data objects in Archimate and BPMN

The picture shows modeling elements from two widely adopted standards: BPMN and Archimate.

Context / Behaviour

A Vendor is usually a stakeholder, and an external party, for our business, As such, it may be represented with a Partner Role element, according to BPMN. This is mainly a reference role, a bookmark, also if we may wish to attach some documentation or classification elements. This element will have a place in BPMN process modeling, as a Participant in a collaboration.

Archimate modeling language includes two elements that can be used as a collaboration participant: Business Role and Business Actor. The Actor is an element modeling something which may or may not have a defined identity (in BPMN Partner Role doesn’t have an identity, while Partner Entity does), but have an independent capability to perform actively some tasks. A Role, on the contrary, is more a formal description of the duties, responsibilities, capabilities, interfaces used and provided, related to a business organizational unit or single person.

So, if we want to emphasize “what the partner does”, we can model it with a Role, but if we have more interest on “what kind of partner is”, we will prefer an Actor. Usually, and Enterprise Architect is interested in the “internal” architecture of his business and, in my opinion, will find the Actor element better suited for this task.

Business Object

This is a typical element of Archimate, representing a wide range of possible items. I usually see the Business Object (a passive element in the Business Architecture Layer) as an element of the business dictionary. In every Company, when you start an interview with people with different roles, you will recognize a number of common “words”. They represent the products, the market, the external parties, the production facilities. They are the better candidates to be represented with a Business Object (behind this analysis, we may like to perform a more detailed ontological analysis on the concepts and relationships, but this is another chapter). At the Business Layer, a Business Object is not an “information item”, but is a collection of information, rules, connection with processes and internal organizational units, that will remain unchanged if we replace the information system with another one, without changing the business architectural layer.

In BPMN there isn’t a corresponding element, but we often use the Data Object to show which activities interacts with some parts of a Business Object. In general, I prefer to limit the “technical data structure pollution” in BPMN diagrams, this means trying to be as abstract as possible with respect to the actual data structure. The BPMN standard encourages this, providing a number of Item Aware Elements, that may reference any kind of physical, logical or informational element.

So, for instance, a process where one of the deliverable is the Vendor Master data, or a new Vendor Dossier, will see the “Vendor” Data Object.

Application and Database

Coherently with the approach followed for Data Objects, I usually use Data Stores to model “logical” database representations, detached from the actual database storing their data. Following the example in this article, we will have a “Purchasing” Data Store, including everything that is connected to the purchasing cycle: items, prices, vendors, orders, deliveries, etc. Someone may observe that a “Vendor” is also relevant in the “Accounting” Data Store, as part of the Accounts Payable, but I don’t agree. We deal with a Vendor because it is a provider of services and goods, not because we have an account opened with his name in our books.

Archimate, on the opposite, makes a clear distinction between the Application/Data layer – where the Data Object will have a strong “structure/database table” meaning, and the Device elements, which is used to represent the actual “hardware” hosting the Database.

Bottom Line

By using a limited number of partially-overlapping modeling standards (in our choice: TOGAF, Archimate, BPMN and UML), we can obtain a powerful and detailed representation of our Business Architecture according to different perspectives and viewpoints. Business Concepts modeling is a key part of the Enterprise Architecture capability, allowing us to catch what is maybe the core knowledge base of our business. Extending upwards (Business interactions and processes) and downwards this modeling layers will give us the ability to track the impact of any change in our business scenario on all the levels of the Architecture.

Archimate uses the “Business Object” element to model a passive entity representing a concept or a business entity manipulated by behavioral business elements.

Creating a catalog of “Business Objects” is useful when you need to analyze links among application, data, process areas.
Consider concepts like “Purchase Order” or “Supplier”: they may appear as data input or output, part of the data architecture, stakeholders, roles in process diagrams.
It’s also important to model the information associated with each Business Objects. For instance, a “Purchase Order” may carry information about the kind and quantity/quality of goods or services, contractual information, cost accounting details, internal organization references (requester, buyer, authorizer). These information can be modeled in two ways:
  • using the “Meaning” element in Archimate;
  • using an aggregation.
I don’t like the second, because, while a Purchase Order has a defined identity and unity, the details of goods, outside the Purchase Order context, is ambiguous, because the same information can be related to a Purchase Request, a Delivery, a stock adjustments, etc.
In my Company, Caltagirone Group, I adopted the first notation, obtaining this kind of diagrams:
Archimate PO Business Object

Read the rest of this entry »

When you decide, or are involved, in an evolution project regarding your Organization division, perhaps your Company is willing to transform it in an Enterprise Architecture Capability, in other words a set of resources dedicated to design and support change management using comprehensive frameworks, like TOGAF.

It’s a good moment to think carefully about your objectives, and you can use TOGAF itself as a supporting framework for this project (TOGAF manual describes this task in the “preliminary” phase).

The core of this activity will be synthesized by:

  • you “as-is” practice, that is your baseline Architecture Capability;
  • the desired target Architecture Capability.

The differences between those two situations will be described using a list of gaps, that will be the starting point for your project definition.

Using Archimate – the modeling language that integrates very well TOGAF in many parts – we can describe these elements.

Archimate diagram illustrating baseline and target architecture capabilities

Archimate diagram illustrating baseline and target architecture capabilities

The figure is only an overview, but the gaps highlighted will guide you through a series of questions that will define your evolution:

  • people and skills involved,
  • organizational position of the Architecture team,
  • usage of internal/external resources,
  • scope (horizontal and vertical) of the analysis,
  • interaction with IT, HR, Board, etc.,
  • tools, standards,
  • project management practice,
  • methodologies,

and so on.

This will be also a good opportunity to start practicing, in your “real” business, your new organizational structure. At the same time, during this project, you will produce – as a deliverable – an initial Enterprise Architecture, covering the basics layer of Business, Data, Application and Technology. This initial Architecture, stored in your Architecture Repository, will be used and refined in your following architectural projects.

During the design of the Business Architecture, in TOGAF, we have to outline the structure of the organization, including the description of how human resources are assigned to roles, organizational units, locations.

The structural element representing the organizational unit in Archimate is the Business Actor. As the standard says, a Business Actor may be “a human, a department, or a business unit”.

This is the main building block of our organization structure design, and can be enough if you want to limit yourself to the traditional hierarchical organization chart. Following this approach, you will find perhaps a missing element: a taxonomy that helps you classify the different elements.

Simple Organization chart with Archimate
This simple vertical organization shows some of the problems and possible solutions:
  • the sales organization is a business unit, with a manager; we suppose that the manager will be a single person.
  • There are more Area Manager; the composition relation shows that the Sales Manager is their direct boss. Again, this “Actor” will perhaps be a single person, but there will be more people in this role, each of them assigned to a different geographical area.
  • Within each “Area”, there are separate managers for each “Product”. All the Product Managers of an Area will report to the Are Manager. The geographical dimension appear to be the prevalent one.
  • Perhaps there is also an orthogonal Product dimension; we can imagine that there is a global Product Manager, it’s not represented here, but is clearly possible.
  • There is a single back office unit, working for the whole sales organization.
Using this really limited set of elements from Archimate, we were indeed able to represent the basic hierarchical organization. Some of the relationships among business units, and the kind of each unit, are somehow ambiguous, requiring an explicative narrative. This is not good, because a modeling standard should be able to represent a situation without disambiguation.
Other modeling standards, such as BPMN, provide the designer with some attributes that are specific for extensions. Archimate includes a generic extension mechanism, trough “attributes” for specific elements, included in a “profile”, or using specialization of standard concepts.
We will see later how to accomplish this, adding some more elements to the model.
Follow

Get every new post delivered to your Inbox.