The Actor, from Archimate, to UML, to BPMN – one

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.

Advertisements

More on information modeling: from business to disk

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.

Starting your Architecture Capability

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.

Cloud based collaboration and office suites

Image The traditional landscape for Office Automation application has changed significantly.

The disruptive new entry was Google. During time, the Mountain View Company has built its online offering over four main pillars:

  • Drive,  this is both a generic cloud storage, but at the same time offers a suite of Office applications (Documents, Spreadsheets, Presentations, Drawing);
  • Gmail, just for mail processing;
  • Hangouts for text, audio, video, chatting;
  • G+, adding a Social platform to the suite.
Microsoft, durign the last years, but mainly during the last months, have followed, with an offering that is similar, by some points of view, but different in non trivial details.
  • Outllok.com offers the mail functionality, integrated with text chat (the old Messenger);
  • One Drive offers the cloud storage functionality, integrated with Office apps, with a subset of the traditional PC based Office suite.
  • Yammer: is the Social component, but in an “Enterprise” flavour. Yammer is the result of an acquisition, and is still under “integration” with the other products.
  • Share Point, in the cloud version, is a derivation of the mature on premise product, with a simpler deployment curve. This product offers an unique, structured, platform for file archiving, that doesn’t compete with Drive, or other similar products, like Dropbox or Box, but rather with platforms like Alfresco.
  • Lync, for internet based video/audio communicaton.
  • One Note, is a mature note taking product, that wasn’t able to gain user traction, leaving space for other competitors like Evernote.
Now, the two competitors are pushing their marketing efforts toward the rich Business market, and this is the big shift that I have introduced at the beginning, and that each CIO should consider carefully.

 

Significantly,  both platforms don’t put a big emphasis on the “mail” component, and both struggle to obtain a good acceptance for their Social apps.
The two things are linked, in my opinion: why any Social app require so a big effort, in a business environment, to conquer the user attention and involvement? 
The answer, I believe, rests in the lack of integration with the mail component. The great part of our daily interaction, at work, comes from mail messages. Managing messages, organizing them, forwarding and processing them, absrorbs the biggest part of the time  that we commit to interaction. This is why few minutes are left for engagement in other collaborative platforms, and we are, somehow, scared of being further involved in other things.

 

The solution would be quite simple: integrate mail in the “stream” of posts that populate our social dashboard. This could work well if we are able to organize mail, posts, documents around the big “themes” that we deal with, projects, prospects, processes.
This require two things:

  1. An intelligent classification system that is able to spot the right hashtag that is to be applied to each message/post;
  2. An intelligent search mechanism, capable of finding related posts/messages/documents, beside the “natural” linking mechanism provided by hashtags.
Another point: the majority of the cloud apps users consider them only as a practical online replacement for the traditional PC versions, enjoying the availability on fixed and mobile platforms. The real time collaboration features are often overlooked. But the ability to work, in real time, by multiple users, on the same spreadsheet or document, while chatting, introduced a new paradigm for collaborative work, that has still a long way to go.