ArchiMate: How would you model the uses of a [business] product?

[Glassboy]

I asked this question on the LinkedIn ArchiMate group without getting a useful answer so I thought it would be useful to ask here.

How would you model the uses of a [business] product?  Some of those uses will be specified as acceptable in the accompanying contract elements related to the product (these may be actual legal contracts or SLAs et al).  Specific uses might be ruled out by the in the documents modelled by contact elements.

[Paolo F Cantoni]

I asked this question on the LinkedIn ArchiMate group without getting a useful answer so I thought it would be useful to ask here.

How would you model the uses of a [business] product?  Some of those uses will be specified as acceptable in the accompanying contract elements related to the product (these may be actual legal contracts or SLAs et al).  Specific uses might be ruled out by the in the documents modelled by contact elements.

What sort of answers did you get in the LinkedIn group and why weren't they useful.

If I understand you correctly, I'd link the product to some form of activity.  You can use it for this activity, but not for that activity.  You can model the contract clauses (or sections) as components of the contract and create n-ary tuples to the product and usage (activity) from the clause.  Is that the kind of thing you're asking?

Paolo

[Glassboy]

What sort of answers did you get in the LinkedIn group and why weren't they useful.

Basically that customer interactions could be represented as Business Services, which isn't useful because the product is a mixture of business services, business objects, and contracts.

If I understand you correctly, I'd link the product to some form of activity.  You can use it for this activity, but not for that activity.  You can model the contract clauses (or sections) as components of the contract and create n-ary tuples to the product and usage (activity) from the clause.  Is that the kind of thing you're asking?

It may actually be that I need to go up a layer and use outcome and constraint.   Our Business Services are basically wrappers around Technology Services that support the customer's application and business services.  I'm trying to create a model for business conversations without diving straight into the crunchy details.

[Sunshine]

Not quite sure what you are after but its clear from the Archimate Spec V3.01 and the book, Enterprise Architecture at Work. A stakeholder gets some value from a product. The product as you say consists of business services, business object and contracts. The business services serve actors and the services are realised by business processes. Application services serve Business Processes. Application Services are realised by application components etc.
You can use interactions to show collective business behaviour and collaborations to connect up two or more roles.
The matrix from page 125 of the spec states what the valid relationships are from product to other elements.
The relationship "serves" now replaces "used by "relationship"
So from the spec valid relationships where the product serves (used by) other elements are

• Actor
• collaboration
• event
• function
• interaction
• interface
• process
• role
• service
• etc

Hope that helps. Happy to meet up for coffee and talk about it further. Just PM me.

[Glassboy]

Not quite sure what you are after but its clear from the Archimate Spec V3.01 and the book, Enterprise Architecture at Work. A stakeholder gets some value from a product. The product as you say consists of business services, business object and contracts. The business services serve actors and the services are realised by business processes.

OK here's a very narrow example.  Let's say at the motivation layer we have a Stakeholder called "Government" who has a driver of "Cheaper Government services".  Which leads to a Requirement for cost effective Internet access.

At the Business layer we have a Product "Government Worker Internet Connection" that realises the Requirement.  It contains a Business Service "Government Worker Internet Connection Service", a number of Contracts that represent the legal contracts and SLAs et al, and a number of Business Objects that represent reports and bills etc.

At the Application Layer there are internal elements that represent internal functionality with minimal interaction with the customer's own application layer.

At the Technology Layer we have a number of Technology Services that the customer does interact directly with.

Now for the interesting bit.  I want to represent at the business layer that the product/serve is constrained only to being used by a living human being employed by the government and can not be used by an autonomous software agent or a hardware agent (server etc).  I don't want to map these restrictions at the Application or Technology Layers as my internal workings at these layers needs to be invisible to the customer.

The actual situation is far far more complex.  But I want to get to somewhere where it is obvious what a solution is solving :-)

[Paolo F Cantoni]

We use two types of relationships for this purpose.  Restriction on and Restricted by (specialized Specialization and Dependency respectively).

For this example, we'd represent "Government Worker Internet Connection" as restriction on "Internet Connection", restricted by "Government Worker".

Paolo

[Glassboy]

We use two types of relationships for this purpose.  Restriction on and Restricted by (specialized Specialization and Dependency respectively).

For this example, we'd represent "Government Worker Internet Connection" as restriction on "Internet Connection", restricted by "Government Worker".

I'm trying to work out whether it there is a vanilla (and sensible) ArchiMate method before I start specialising elements or relationships.

[Sunshine]

Not quite sure what you are after but its clear from the Archimate Spec V3.01 and the book, Enterprise Architecture at Work. A stakeholder gets some value from a product. The product as you say consists of business services, business object and contracts. The business services serve actors and the services are realised by business processes.

OK here's a very narrow example.  Let's say at the motivation layer we have a Stakeholder called "Government" who has a driver of "Cheaper Government services".  Which leads to a Requirement for cost effective Internet access.

At the Business layer we have a Product "Government Worker Internet Connection" that realises the Requirement.  It contains a Business Service "Government Worker Internet Connection Service", a number of Contracts that represent the legal contracts and SLAs et al, and a number of Business Objects that represent reports and bills etc.

At the Application Layer there are internal elements that represent internal functionality with minimal interaction with the customer's own application layer.

At the Technology Layer we have a number of Technology Services that the customer does interact directly with.

Now for the interesting bit.  I want to represent at the business layer that the product/serve is constrained only to being used by a living human being employed by the government and can not be used by an autonomous software agent or a hardware agent (server etc).  I don't want to map these restrictions at the Application or Technology Layers as my internal workings at these layers needs to be invisible to the customer.

The actual situation is far far more complex.  But I want to get to somewhere where it is obvious what a solution is solving :-)

Okay that explains a bit. Your working for a telco providing a technology service to Government. Thanks for the heads up on getting cheaper internet services

Not sure if I'd model that at the business layer. I'd be tempted to model it something like this.

Stakeholder: Government
Driver: Cost
Assessment: Internet Service too expensive
Goal: Reduce Internet Services Costs
Requirement: Provide competitively priced internet service to Government
Work package: Create a Competitively priced Internet Service for Government Workers.
Technology Service: Government Internet Service
Technology Processes: Subscribe to Internet Service, Install Internet Connection, Consume Internet Service, Unsubscribe from Internet Service
Technology Object (Fact): Type of Internet User [Human|Machine|...]
Technology Object (Fact): Employment 
Technology Interface: Internet Connection
Technology Function (business rule): Allow Connection -{When connection requested if human AND employed by Government then connect else do not connect.}

The consumer of the service sees the technology service and interface but nothing else.
As a Government Enterprise Architect I could then show how Government Products and Services can utilise such technology services.

[Glassboy]

The consumer of the service sees the technology service and interface but nothing else.
As a Government Enterprise Architect I could then show how Government Products and Services can utilise such technology services.

Well sort of.  You as a Government Enterprise Architect involved in the secondary procurement processes have a bunch of drivers and requirements separate to those of the Government Architect involved in the primary procurement.  If you have a an organisational goal to outsource or subscribe to services for everything that isn't your core function you'd don't want to discover six months in you haven't bought the right set of products to do everything you used to have staff doing.

But I hadn't thought about modeling a fact as a business object.  I could use those facts to realise a number of constraints at the motivation layer that are exposed upwards.  I can probably also use the approach to model a product bundle that delivers to a goal.

BTW this isn't specifically a Telco issue.  It's a service provider issue.  I'm just trying to build a standard set of artifacts that can go back to a "customer" and the vendor / primary purchaser / secondary purchaser aspect makes that a bit weird sometimes.