Using ArchiMate 2.1 to Model Product or Service Markets

In the LinkedIn ArchiMate group, Toon Wijnands posted a query asking

I’m looking for the concept of modelling ‘Market’. I’m referring to the markets a company is active at. e.g. you could have a B2C market and a B2B market, or USA market, European market, Asian market.
[Any suggestions on how to model the concept ‘Market’ in ArchiMate?]

My response was:

Michael Herman (Toronto) I recommend using a Location to represent a Market and to aggregate the concepts that are relevant to each market and to your model’s goals. This includes using Location as an abstraction for specific B2B and B2C markets – making sure to document this practice in your EA governance document.

The aggregated concepts can [be] nested within each Location as a mini-model. Each mini-model can include Stakeholders (including specific or representative, customers, government entities, other regulatory bodies, competitors, etc), as well as Constraints and Requirements imposed by the preceding Stakeholders, etc. The market-specific set of Constraints and Requirements can then be linked to a possibly smaller, more uniform set of Drivers.

Ownership and updating of the Market mini-models, singly or in total, can be given to a member of your EA team or a business client within your organization. Elaborate Market models can be licensed or sold – but I’m getting off topic.

As a follow-up, here’s a concrete example using ArchiMate 2.1 and the Archi modeling tool; including the exact steps I followed to create a Market mini-model.

Start at the top: Most Markets are defined by their Stakeholders: Customers (or their Personas), Competitors, and Government Agencies (and perhaps, other regulatory or standards bodies). Use these to drive out a selected set of Drivers and Goals for your next product release. Of course, the current state of your Market model doesn’t have to respond to every Stakeholder or Driver.  Include all of these in the model but, in the current state of the model, only include the Goals you are trying to satisfy in the next release. From the Goals, derive more specific product or service Requirements.

In addition, add a Market Research Team as a Stakeholder to document specific market analyses or Assessments as part of your mini-model; linking these to a new or existing set of Goals.

You’ll end up with something like the following. Click to enlarge.

Markets 0

Of course, the current state of your Market mini-model doesn’t have to respond to every Stakeholder or Driver.  Include all of these in the model but, in the current state of the model, only include the Goals you are trying to satisfy in the next release. From the Goals, derive more specific product or service Requirements.

TIP: Because of the way ArchiMate works, make sure each Driver, Goal, Assessment, Requirement, etc. is linking to a Stakeholder; hence, the reason for creating the Market Research Team stakeholder.

TIP: Consider creating 3 views (I call them Construction Views) to help you track your work. In my model, I called them Markets 0, Markets 1, and Markets 2.  The above view is Markets 0.

Then select all of the elements of your Market mini-model, and drag and drop them onto a Location element (named Market M in the above example) to get the second version (view) of the model.

TIP: Different ArchImate modeling tools handle this action in different ways. In my example, Archi prompts you to add Assignment relations to relate each of the 5 Stakeholders to the Market M location element. I’ll talk more about this later.

…and voila!, here is one example of a Market mini-model.  Use the same technique to create mini-models for your additional markets. Click to enlarge.

Markets 1

What’s going on behind the scene views?

To understand how ArchiMate (and Archi) chose to model this scenario, after you’ve dragged and dropped your mini-model onto the Location element and accepted the creation of the new Assignment relations, do the reverse: select all of the mini-model elements nested inside the Location and drag and drop them outside of the Market M location element.  Your (third) view should look something like the following. Click to enlarge.

Markets 2

The Market M Location element is related to each Stakeholder using the automatically created Assignment relations.  The rest of the mini-model is related to the Location element via Derivation. This is why it was important to have the Assessment, Driver, Goal, Requirements, etc. elements related to a Stakeholder.

Every language (conventional or technical) has its idiosyncracies. Use ArchiMate and make it work in a way what works best for you and your organization.

Best regards,
Michael Herman (Toronto)

p.s. Please add your feedback in the Comments section below.  How can this idea be improved?

4 Comments

Filed under ArchiMate, Architecture Reference Models, Enterprise Architecture, Product Management, The Open Group

Progressive​ Enterprise Architecture Maps – Update 2

Pavel Harbe asked an interesting question with respect to the original version of the Progressive Enterprise Architecture Map: “Why … is Strategy first and then Motivation and not in opposite order (or in many iterations)?” and goes on to explain that, yes, in fact Motivation should precede Strategy (at least initially, and then followed by possibly several iterations).  Of course, Pavel is correct …but so is the diagram (see below). However, Pavel’s comments do indicate a need to clarify these points – here in text as well as in a new version of the Progressive Enterprise Architecture Map.

Progressive EA Model 1-0-3-NoArrows-Slide

*Original discussion: Progressive Enterprise Architecture Maps

To respond directly to Pavel’s question, the subtlety in the original diagram can be found in text beneath the caption of each layer (emphasis added for this explanation):

  • Strategy refers to the “Strategy of the *Enterprise*”, the organizational strategy.
  • Motivation refers to the “Intentions of the *Architecture*”, a phrase borrowed from Gerben Wierda’s original discussion (An ArchiMate 3 Map (Layers? What Layers!))

The original diagram referred to the strategy of the organization driving the motivations [intentions] for the companion enterprise architecture.

Given pragmatic usefulness is one of my goals for the Progressive Enterprise Architecture Map (while at the same time preserving architectural simplicity), the following elaboration is warranted: adding 2 more layers to clarify the levels at which Strategy and Motivation are used to drive continuous transformation of the organization and its enterprise architecture.  Here is version 2 of Progressive Enterprise Architecture Map.

Progressive EA Model 1-0-3-PEAM2-Slide

On the left side of the diagram, there is a distinct pair of Motivation and Strategy layers for enterprise-level strategy planning.  In addition, there is a distinct pair of these 2 layers which transform the enterprise-level drivers, goals, and strategies into drivers, goals, and strategies for the enterprise architecture. You can argue these should be the same but due to many reasons such as timing and resources, they are not always the same.

Progressive Enterprise Architecture Maps, Continuous Transformation, and Total Enterprise Architecture Managment

Given this elaboration, I decided to “take it all the way” and link Progressive Enterprise Architecture Maps to Continuous Transformation and Total Enterprise Architecture Managment – topics I’ve discussed and modeled in the article [Enterprise Architecture] Tools and Methods Don’t Create Business Value.  The model for Continuous Transformation and Total Enterprise Architecture Managment looks like the following:

Parallelspace-Business Value from Transformative Change4

Here’s version 3 of the Progressive Enterprise Architecture Map (linked to Continuous Transformation and Total Enterprise Architecture Management).

Progressive EA Model 1-0-3-PEAM3-Slide

Best regards,
Michael Herman (Toronto)

1 Comment

Filed under ArchiMate, Architecture Reference Models, Enterprise Architecture, Progressive Enterprise Architecture Map (PEAM)

Crossing the Chasm: Progressive​ Enterprise Architecture Model (PEAM)

[Updated October 5, 2016]

Inspired by Gerben Wierda’s thoughtful discussion about how the full framework is depicted in the new ArchiMate* 3.0 specification (An AchiMate 3 Map (Layers? What Layers! — 1)), I’m going to suggest there’s another level of improvement that can be made to the specification’s “peanut butter and jelly sandwich” diagram. [Please excuse the visual metaphor but that’s what it looks like – with PB&J leaking out on all sides.]

image004

Figure 1. ArchiMate 3 Layers and Aspects

In his posting, Gerben suggests a succession of improvements (depicted below).

This slideshow requires JavaScript.

Figure 2. Gerben Wierda’s Suggested Improvements

But they still left my question unanswered: Why were Strategy, Motivation, Implementation & Migration left as disconnected layers on opposite sides of the enterprise architecture map? [I don’t accept Motivation being classed as an Aspect but that’s a topic for another article.]

What happened to the architectural principles of simplicity and elegance?

Aren’t the following series of enterprise architecture maps more informative and more understandable?  …more pragmatically useful?  I refer to the version below as the Progressive Enterprise Architecture Map.

Progressive EA Model 1-0-2-Base-Slide

Progressive EA Model 1-0-2-Layers-Slide

Progressive EA Model 1-0-2-Aspects-Slide

Progressive EA Model 1-0-2-Both-Slide

Figure 3. Progressive Enterprise Architecture Model: Progressive Enterprise Architecture Map

Check them out for yourself and please add your feedback in the Comments section below. Click on any diagram to see a larger version.

Best regards,
Michael Herman (Toronto)

p.s. If the arrows make the enterprise architecture map too prescriptive from a pure ArchiMate specification perspective, what do you think of this version?

Progressive EA Model 1-0-3-NoArrows-Slide

p.p.s. In October 2016, in the article Crossing the Enterprise Architecture Chasm, I extended PEAMs to include:

  • Continuous Transformations
  • Strategy Chasm
  • Enterprise Architecture Chasm

Here’s an example (click to enlarge):

progressive-ea-model-1-0-6-peam3-chasms

*ArchiMate is a registered trademark of The Open Group.

6 Comments

Filed under ArchiMate, Architecture Reference Models, Automated Application Architecture Analysis, Crossing the EA Charm, Enterprise Architecture, Progressive Enterprise Architecture Map (PEAM), The Open Group

Periodic Table of Visualization Methods

periodic_table

Leave a comment

June 15, 2016 · 9:13 pm

MS Azure is a bit of a bucket of bolts …very good bolts …but relative to the other IoT vendors, a bucket of bolts.

Michael Herman: Yes, there’s lots of “stuff” but I don’t see any content that targets Architects in the same effective ways that the [other vendor] content does. MS Azure is a bit of a bucket of bolts …very good bolts …but relative to the other IoT vendors, a bucket of bolts. Where’s the equivalent of a Google map that shows me the least cost or least complexity or hyper-performant architectures for receiving events, processing them through an easily composable and implementable pipeline of post-processing steps, and then persist the results and make them available through Power BI? …without constantly having to dig through the bucket or using Web Jobs as band-aids between every pair of Azure services?

Microsoft: Michael – are these more of what you had in mind:
https://azure.microsoft.com/en-us/documentation/articles/iot-suite-remote-monitoring-sample-walkthrough/
https://azure.microsoft.com/en-us/documentation/articles/iot-suite-predictive-walkthrough/
The Azure IoT Suite preconfigured solutions are actually implementations of the IoT Suite Reference Architecture you refer to above.
Thanks for the feedback, we’re actually discussing having more of an architectural center right now internally – can you provide more information on what you’d like to see?

Michael Herman: What does Nirvana look like? An Expedia-like traveling booking experience for all of Microsoft Azure where I provide my departure point, destination(s), and all the points in between (stopovers) and Microsoft produces a series of “flight options” (detailed architectures with *diagrams* and customizable blueprint/recipe documentation) where each option is differentiated by Azure cost, complexity, and performance …just like booking a flight. I get to choose the option (aka architecture) that suits my requirements and budget. Simple 😉

1 Comment

Filed under Uncategorized

Subject: MS Azure Services: Is there an overarching architectural vision?

From: Michael Herman (Parallelspace)
Sent: Monday, May 16, 2016 7:58 AM
To: Mark Russinovich; Scott Guthrie
Subject: MS Azure Services: Is there an overarching architectural vision?

Hi Mark and Scott,

I’m pretty sure that you and I have never met – although I’ve been building apps on the Windows platform since 1986 (version 0.989 of the SDK) and I worked for MSFT from 1996-2001 – mostly on the SharePoint team.

My question is: Is there an overarching architectural vision for the (complete) MS Azure platform? There doesn’t appear to be and I’ll give you an example in a second.

It appears like we’re back in 1996 when Billg/Microsoft finally “got the Internet” and every product group began a completely different, disconnected, uncoordinated effort to add “Internet” to their own little piece of software (e.g. HTML publishing mostly; support for some Internet protocols; etc.) Every day something new was being “released to the web (RTW)” and the Microsoft platform was a mess.

What I saw with Microsoft and the Internet in 1996 is happening all over again with the Microsoft Azure strategy: a disconnected and uncoordinated and not well documented strategy and implementation. Azure [as a strategic platform] is a mess.

My example: MS Azure services, MS IoT Suite, MS Cortana Suite, Azure Logic Apps.

The whole MS approach to Azure Event Hubs is extraordinary (good): Lightweight, inexpensive, brain-dead easy to use, largely unrestricted in terms of how Event Hubs can be used and the use cases they can support.

If I have some event data in an Event Hub, the very next thing I want to do is perform some post-processing of the event data – ideally staying with a streaming, hyper-scalable architecture. I [also] want to create an easily composable pipeline of activities that each perform some sort of processing of each event as the events progress through the pipeline. I want the pipeline activities to be easy to design and implement (e.g. kind of like PowerShell cmdlets but it doesn’t have to that specific implementation pattern but with a similar simple pattern that is easy to build upon).

But which MS Azure services have native support for consuming event data stored in an Azure Event Hub? …almost none

…except for Azure Stream Analytics. But what about Azure Data Factory? What about Azure Logic Apps? Are there other Azure Services I should be considering? …without having to build and manage [several] custom Azure WebJobs and use all sorts of intermediate Azure storage just to connect the applicable Azure services together?

Of the 3 options I listed, you chose the one, Azure Stream Analytics, that has [the] most baroque programming model (some SQL derivation). None of the latter two have any native support for event data stored in an Event Hub and they are a lot easier to use than Stream Analytics SQL scripts.

Where is the Azure documentation that is targeted at Architects?

The MS IoT Suite team has started a good MS IoT Reference Architecture document: http://download.microsoft.com/download/A/4/D/A4DAD253-BC21-41D3-B9D9-87D2AE6F0719/Microsoft_Azure_IoT_Reference_Architecture.pdf

Where is the consistent set of similar documents for the other collections of MS Azure services? Where is the overarching MS Azure architecture document?

Given a starting point and a goal (and some intermediate subgoals), where is the “Google Map” of all of the possible connections and routings across all of the MS Azure services?

MS Azure-Google Map

Can you help?

Best regards,
Michael Herman (Toronto)

1 Comment

Filed under Uncategorized

NASA Apollo 11 Flight Plan – July 1, 1969

#notetoselfonly

Click here: NASA Apollo 11 Flight Plan – July 1, 1969

Michael Herman (Toronto)

1 Comment

Filed under Enterprise Architecture, General, Space Flight

What’s the difference between improving the design and operation of an aircraft engine vs. an enterprise?

Answer: Nothing

Continuous Transformation 2

Continuous Transformation 1.png

Continuous Transformation is a key principle of the Progressive Enterprise Architecture Model (PEAM); part of the practice of Total Enterprise Architecture Management (TEAM).

Best regards,
Michael Herman (Toronto)
Parallelspace Corporation

mwherman@parallelspace.net

1 Comment

Filed under Architecture Reference Models, Business Value, Crossing the EA Charm, Enterprise Architecture, Enterprise Architecture Chasm, Progressive Enterprise Architecture Map (PEAM), The Open Group

Parallelspace Mentoring and Remediation Services for Microsoft Azure IoT Suite

Parallelspace Mentoring and Remediation Services for Microsoft Azure IoT Suite is a coaching and consulting service targeted at Microsoft customers and partners who are evaluating or implementing solutions based on the Microsoft Internet of Things (IoT) Suite on top of the Microsoft Azure platform.

This slideshow requires JavaScript.

For more details, contact:

Michael Herman
Principal Architect
Parallelspace Corporation
mwherman@parallelspace.net
(416) 524-7702

Leave a comment

Filed under Uncategorized