Category Archives: Uncategorized

#Graphitization of the Amazon Leadership Principles (introducing Personal Leadership Principle Maps) – Iteration 1

COPYRIGHT © 2016-2017 by Michael Herman, Toronto, Canada. All rights reserved.

[Click on any figure to enlarge it to its full, original size.]

The motivation and goals for Iteration 1 of this project are simple:

  1. Make the Amazon Leadership Principles visually more understandable and more memorable
  2. Introduce the concept of a Personal Leadership Principles Map where one’s personal career and personal belief system is mapped to each of the Amazon Leadership Principles
  3. Promulgate the use and application of #Graphitization beyond its traditional roots in Enterprise Architecture.

This article is structured as follows:

  • Appendix B – Amazon Leadership Principles is copy of the original text (non-graphitized) version of the Amazon Leadership Principles from the Amazon Jobs website.
  • Appendix A – Amazon Leadership Principles (and Subprinciples) contains an ArchiMate enterprise architecture model that depicts the (and then decomposes) the 14 Amazon Leadership Principles into multiple levels of subprinciples. Scroll down to the bottom of this article to check it out.
    NOTE: The underlining in Appendix A attempts to highlight the individual Subprinciples and Relationships found in the text description of each of the 14 Principles.
  • The first real section Amazon Leadership Principles, Core Entities, and Relationships presents a new innovative way to learn, remember, understand, and apply the Amazon Leadership Principles as highly visual web (or mesh or graph) of principles, concrete entities, abstract entities, and relationships.
  • The last section (just before Appendix A), entitled Personal Leadership Principle Maps, depicts how the experiences and accomplishments of one person’s career (mine) can be (formally) mapped the Amazon Leadership Principles.

Let’s start the journey. If you’re not familiar with the Principles, start by reading:

  • Appendix B – Amazon Leadership Principles; then
  • Appendix A – Amazon Leadership Principles (and Subprinciples)

All of the figures in this article represent different graphitized views of the Amazon Leadership Principles (click here) …all built from a single underlying graph model (which, in total, is referred to as the #Graphitization of the Amazon Leadership Principles).

Visually, the model is expressed using the ArchiMate 3.0 visual language standard for enterprise architecture. The model was built with the latest version of Archi 4.0, the open-source, free enterprise architecture modeling platform.

If you would like to work directly with the ArchiMate model for the Amazon Leadership Principles,

This article concludes with a list of possible Next Steps for Iteration 2.

Enjoy.

Amazon Leadership Principles, Core Entities, and Relationships

The text of the Amazon Leadership Principles references specific:

  • Roles
  • Concrete entities,
  • Abstract Entities, as well as, more importantly,
  • Relationships between these entities

These are collectively referred to as the Core Entities. Roles include:

  • Leader
  • Owner
  • Customer
  • Competitor
  • Partner
  • etc.

Concrete Entities include:

  • The Amazon Organization (presented by an employee directory or org chart)
  • Employee Team (same including virtual teams documented in project documents)
  • Standards (assuming they are written down or, in other words, documented)
  • Products
  • Services
  • Processes
  • etc.

Abstract Entities include:

  • Speed
  • Calculated Risks
  • Decisions
  • Actions
  • Inputs
  • Results
  • Bold Directions
  • Capabilities
  • etc.

Relationships include:

  • Leaders obsess over Customers
  • Leaders pay attention to Competitors
  • Leaders earn and keep Customer Trust
  • Constraints breed Resourcefulness
  • Constraints breed Self-Sufficiency
  • Constraints breed Invention
  • etc.

All of the entities and relationships are depicted in Figure 1 below (assuming none or only a few have been overlooked). (Click the figure to enlarge it.)

The entities and relationships were deduced by inspection and analysis of each of the 14 Amazon Leadership Principles (classic business analysis, more or less).

Parallelspace-Amazon Leadership Principles, Roles, and Relationships-P00-Core Entities v1.30

Figure 1. Amazon’s Principles, Core Entities, and Relationships: The Core Model

The existence, enablement, creation and/or execution of each group of relationships gives rise to (or realizes) one or more of the 14 Principles (and/or their Subprinciples). When these realization relationships are added to the Core Entities depicted in Figure 1,  Figure 2., the “Complete Model”, is the result. (Click to enlarge.)

Parallelspace-Amazon Leadership Principles, Roles, and Relationships-P00-All v1.30

Figure 2. Amazon’s Principles, Core Entities, and Relationships: The Complete Model

To simplify the understanding of the model, 14 new views were created – one for each of the 14 Principles – each overlayed on the original Core Model (Figure 1). Figure 3 is an example drawn from one of these 14 views: Principle 1. Customer Obsession.

Parallelspace-Amazon Leadership Principles, Roles, and Relationships-P01 v1.30

Figure 3. Amazon’s Principles, Core Entities, and Relationships: Principle 1. Customer Obsession

Located in the lower-left side of Figure 3, the Customer Obsession Principle is realized by:

  • a) a Leader’s focus or “obsession over Customers”, and
  • b) a Leader’s “attention to the Competition”.

Figure 4. below is an animation of the Complete Model overlayed, principle-by-principle, against the Core Model.

This slideshow requires JavaScript.

Figure 4. Amazon’s Principles, Core Entities, and Relationships: Principle-by-Principle Animation overlayed against the Core Model

The individual views of the 14 Amazon Leadership Principles can be downloaded from here: https://www.facebook.com/mwherman/media_set?set=a.10155018158800932.1073741988.635655931&type=3.

So far, we’ve addressed the “what” of the Amazon Leadership Principles depicted as a #Graphitization model projected as a number of different views.

In the next section, the Amazon Leadership Principles are used as a framework for cataloging one’s lifetime experiences and accomplishments. Personal Leadership Principle Maps is an Amazon Leadership Principles application – it’s the Amazon Leadership Principles put into action.

Personal Leadership Principle Maps

Have you been living an Amazon Leadership Principled career/faith/life?

Figure 5. is a copy of my Personal Leadership Principle Map (PLPM).

  • ArchiMate Assessment entities are used to model specific experiences and accomplishments.
  • ArchiMate Outcome entities are used to model specific evidence, learnings, or proof that one has been able to apply the specific principle in their career, faith and/or life.

Parallelspace-Amazon Leadership Principles-Personal Leadership Principle Map-Michael Herman v1.30

Figure 5. Amazon’s Principles: Michael’s Experiences and Accomplishments

In my case, for Principle 7. Insist on the Highest Standards, I have specific experiences related to the recent Toronto Salesforce 2017 Tour, working at Parallelspace Corporation, the IBM Canada Toronto Software Lab, and at Microsoft.

Specific evidence includes:

  • Parallelspace trust framework (Relationships-Reputation-Trust)
  • Working as an ISO-9000 Quality Analyst and a certified Quality Assurance Auditor
  • A concept I call focusing on the success of an Individual Individual
  • Various and diverse experiences working for Microsoft as a full-time employee (blue badge) and as a Microsoft partner

Next Steps for Iteration 2

Possible next steps include:

  • Federation of Personal Leadership Principle Maps – at the Employee Team, business unit, or Organization level to discover the aggregates collective experiences and accomplishments for the purpose of rebalancing hiring objectives (Principle Gap Analysis), accumulating customer as well as competitive intelligence, etc. to support Customer Obsession, Ownership, Invent and Simplify, etc. goals and objectives. Identifying the best sources of experiences and accomplishments for specific Principles based on a Team’s or Organization’s previous roles, education, or training.
  • Use of both the Core Model and the Complete Model as well as the Federate Personal Leadership Principle Maps to create a graph database repository to real-time query analysis and visualization (e.g. using the Neo4j graph database).
  • To support Amazon’s operational data analysis needs (e.g. Amazon Marketplace 3rd Party Retail Data).
  • Apply the Parallelspace principles

References

  1. Continuous Transformation and Transformative Change are key principles of the Total Enterprise Architecture Model (TEAM) (click here)
  2. To dig deeper, check out Graphitization of the Enterprise (click here)
  3. [Enterprise Architecture, Big Data, CRM, ERP, …] Tools and Methods Don’t Generate Business Value (click here)

Appendix A – Amazon Leadership Principles (and Subprinciples)

Below is an ArchiMate enterprise architecture model that depicts (and then decomposes) the 14 Amazon Leadership Principles into multiple levels of subprinciples (as appropriate/as required).

These are based on the text-based defintions of the 14 Principles found in Appendix B – Amazon Leadershp Principles.

Parallelspace-Amazon Leadership Principles (and Subprinciples) v1.30

Figure 6. Amazon’s Principles (and Subprinciples)

Appendix B – Amazon Leadership Principles

The following Leadership Principles are taken directly from the Amazon Jobs website.

  • The sequential numbering (in parenthesis) was added by me.
  • The underlining attempts to highlight the individual Subprinciples and Relationships found in the text description of each of the 14 Principles.

Leadership Principles

Our Leadership Principles aren’t just a pretty inspirational wall hanging. These Principles work hard, just like we do. Amazonians use them, every day, whether they’re discussing ideas for new projects, deciding on the best solution for a customer’s problem, or interviewing candidates. It’s just one of the things that make Amazon peculiar.

Customer Obsession (1)

Leaders start with the customer and work backward. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.

Ownership (2)

Leaders are owners. They think long term and don’t sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say “that’s not my job”.

Invent and Simplify (3)

Leaders expect and require innovation and invention from their teams and always find ways to simplify. They are externally aware, look for new ideas from everywhere, and are not limited by “not invented here”. As we do new things, we accept that we may be misunderstood for long periods of time.

Are Right, A Lot (4)

Leaders are right a lot. They have strong judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs.

Learn and Be Curious (5)

Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them.

Hire and Develop the Best (6)

Leaders raise the performance bar with every hire and promotion. They recognize exceptional talent and willingly move them throughout the organization. Leaders develop leaders and take seriously their role in coaching others. We work on behalf of our people to invent mechanisms for development like Career Choice.

Insist on the Highest Standards (7)

Leaders have relentlessly high standards – many people may think these standards are unreasonably high. Leaders are continually raising the bar and driving their teams to deliver high-quality products, services, and processes. Leaders ensure that defects do not get sent down the line and that problems are fixed so they stay fixed.

Think Big (8)

Thinking small is a self-fulfilling prophecy. Leaders create and communicate a bold direction that inspires results. They think differently and look around corners for ways to serve customers.

Bias for Action (9)

Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.

Frugality (10)

Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention. There are no extra points for growing headcount, budget size or fixed expense.

Earn Trust (11)

Leaders listen attentively, speak candidly, and treat others respectfully. They are vocally self-critical, even when doing so is awkward or embarrassing. Leaders do not believe their or their team’s body odor smells of perfume. They benchmark themselves and their teams against the best.

Dive Deep (12)

Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ. No task is beneath them.

Have Backbone; Disagree and Commit (13)

Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.

Deliver Results (14)

Leaders focus on the key inputs for their business and deliver them with the right quality and in a timely fashion. Despite setbacks, they rise to the occasion and never settle.

Best regards,

Michael Herman
Enterprise Architect and Data Scientist
Parallelspace Corporation
M: 416 524-7702
E: mwherman@parallelspace.net
B: http://hyperonomy.com
L: https://www.linkedin.com/in/mwherman/recent-activity/posts/
Skype: mwherman2000

Living at the intersection of Enterprise Architecture, Enterprise Knowledge, and Data Science

2 Comments

Filed under ArchiMate, Architecture Reference Models, Business Value, continuous transformation, Definitions, Enterprise Architecture, graph database, Graphitization, How do we think, ModelMate, Process, Product Management, Uncategorized

Why Would You Prefer to Work for Amazon (or Facebook) over Microsoft (or Salesforce)? [WIP]

COPYRIGHT © 2016-2017 by Michael Herman, Toronto, Canada. All rights reserved.

This article is a work-in-progress [WIP] placeholder.

Why would you prefer to work for Amazon (or Facebook) over Microsoft (or Salesforce)?

Scenario 1: These are organizations with an unrelenting, unbelievable, and successful focus on happy customers. …a true, genuine, deliberate focus on building and maintaining positive relationships with their customer and partners? Would you choose to work for a Scenario 1 organization? …maybe.

Scenario 2: These are the other companies that really need your help and are willing to hire you to help make the important changes necessary to develop the same sort of unrelenting focus on building and maintaining positive customer and partner relationships Would you choose to work for a Scenario 1 organization? …maybe.

I have the option (luxury) to consider all 4 types of opportunities and in each case, work with some brilliant people. Which organization(s) would you pick?

With a Scenario 2 company, you’re starting work working for an organization in a net deficit position with respect to customer happiness, respect, and trust. Job one is to move the organization from a net negative position to a net neutral or, hopefully, positive position in the marketplace; then build of there. If you know or deeply understand the Scenario 2 company, you’re likely being asked “to return and to help” as a trusted soldier. You likely know and understand the root causes that have landed the organization at the bottom of the ladder of customer satisfaction.

With a Scenario 1 company, you’re starting work working for an organization in a net positive position with respect to customer happiness, respect, and trust. There is no Job one because the organization already has a great positive report with its customer and partners – not just its largest revenue-generating customers but all customers; from

  • Individual individuals

up through

  • Single-person corporations,
  • Two-person partnerships,
  • Small businesses/enterprises,
  • Medium size businesses/enterprises,
  • Large businesses/enterprises, and
  • Extra large businesses/enterprises.

Scenario 1 organizations are already at or near the top of the customer satisfaction mountain and are only striving to be even better. They and yourself are not starting work each day working in a negative hole. Thriving is thriving …thriving to be your best from a positive starting position of customer and partner happiness, respect, and trust.

Scenario 2 organizations start work each day in a negative hole. Yes, there may be places where, on some days, you can stand on something to see over the top of the hole and things don’t look so dreary …but it’s not guaranteed …and it’s neither fun nor enjoyable to work there every day. Thriving is equivalent to surviving.  #NotFun

Amazon

TODO

#Graphitization of the Amazon Leadership Principles (introducing Personal Leadership Principle Maps) – Iteration 1
https://hyperonomy.com/2017/05/08/amazons-principles/

TODO

Facebook

TODO

Microsoft

TODO

Salesforce

TODO

Best regards,

Michael Herman
Enterprise Architect and Data Scientist
Parallelspace Corporation
M: 416 524-7702
E: mwherman@parallelspace.net
B: http://hyperonomy.com
L: https://www.linkedin.com/in/mwherman/recent-activity/posts/
Skype: mwherman2000

Living at the intersection of Enterprise Architecture, Enterprise Knowledge, and Data Science

Leave a comment

Filed under Uncategorized

High-Velocity Service Packages and Envelopes [WIP]

COPYRIGHT © 2016-2017 by Michael Herman, Toronto, Canada. All rights reserved.

This article is a work-in-progress [WIP] placeholder.

TODO

Introduction

TODO

Scenario

TODO

Problem

TODO

Analysis

TODO

Options

TODO

Solution

TODO

High-Velocity Service Envelopes (HVSE)

TODO

High-Velocity Service Packages (HVSP)

TODO

Results

TODO

Next Steps

TODO

Conclusions

TODO

Best regards,

Michael Herman
Enterprise Architect and Data Scientist
Parallelspace Corporation
M: 416 524-7702
E: mwherman@parallelspace.net
B: http://hyperonomy.com
L: https://www.linkedin.com/in/mwherman/recent-activity/posts/
Skype: mwherman2000

Living at the intersection of Enterprise Architecture, Enterprise Knowledge, and Data Science

Leave a comment

Filed under Uncategorized

Isomorphic Weighted Graph Databases and Graph Algorithm Non-Collinearity [WIP]

COPYRIGHT © 2016-2017 by Michael Herman, Toronto, Canada. All rights reserved.

This article is a work-in-progress.

Introduction

TODO

Isomorphic Weighted Graphs

TODO

Definitions

TODO

isomorphic

TODO

Weighted Graph Database Scenarios

TODO

  1. Project “Matt-itrage”: Real-time, Multiple Provider, Foreign Currency Arbitrage
  2. “Expedia for Azure, AWS, and/or Salesforce”: Automated Cloud Services Composition
  3. Project “Boston”: Personal, Hyper-scalable Homeland Security Databases – Federation Optional
  4. TEAM: Large Scale, Automated Total Enterprise Architecture Management
  5. TEBD: Large Scale, Automated Total Enterprise Big Data Routing and Streaming

TODO

1. Project “Matt-itrage”: Real-time, Multiple Provider, Foreign Currency Arbitrage

TODO

Currency Arbitrage

TODO

2. “Expedia for Azure, AWS, and/or Salesforce”: Automated Cloud Services Composition

TODO

3. Project “Boston”: Personal, Hyper-scalable Homeland Security Databases (Federation Optional)

TODO

4. TEAM: Large Scale, Automated Total Enterprise Architecture Management

TODO

5. TEBD: Large Scale, Automated Total Enterprise Big Data Routing and Streaming

TODO

Graph Algorithm Non-Collinearity

TODO

Definitions

TODO

collinear

TODO

collinearity

TODO

Best regards,

Michael Herman
Enterprise Architect and Data Scientist
Parallelspace Corporation
M: 416 524-7702
E: mwherman@parallelspace.net
B: http://hyperonomy.com
L: https://www.linkedin.com/in/mwherman/recent-activity/posts/
Skype: mwherman2000

Living at the intersection of Enterprise Architecture, Enterprise Knowledge, and Data Science

1 Comment

Filed under Uncategorized

Structuring Small Powerful Documents

COPYRIGHT © 2016-2017 by Michael Herman, Toronto, Canada. All rights reserved.

For the past couple weeks now, I’ve been on the left coast visit with friends and colleagues and having an extraordinary time. Often, the conversation returns to what is the best way to convince someone or some group to do this or that.  Here’s some ideas and templates to consider based on my past experiences:

  • Notes from the Field
  • Product Planning Cycles
  • Project Business Charter
  • Preliminary Vision and Scope Document
  • Jeff Bezzo’s Amazon 6-Pager

Notes from the Field

Parts

  • Introduction
  • Scenario
  • Problem
  • Analysis
  • Options
  • Solution
  • [Preliminary] Results
  • Summary

Sample Templates

Product Planning Circles

Sample Templates

Project Business Charter

Parts

  • Business Project Description
  • Deliverables
  • Project Scope / Boundaries / Assumptions
  • Project Accountability
  • Stakeholders
  • Project Execution Risks Summary and Mitigation Options
  • Project Cost Estimate
  • Links to Supporting Documentation

Sample Templates

Preliminary Vision and Scope Document

Also known as an Engagement Transition Document

Parts

  • OVERVIEW
  • PROBLEM STATEMENT
  • BUSINESS OBJECTIVES
  • EXISTING ENVIRONMENT
  • USER PROFILES
  • SOLUTION VISION
  • PROJECT SCOPE
  • CRITICAL SUCCESS FACTORS
  • IMPORTANT DATES
  • OTHER ASSUMPTIONS AND CONSTRAINTS

Sample Templates

Jeff Bezo’s Amazon 6-Pager

Parts

[The six-page narratives are structured] like a dissertation defense:

  1. The context or question.
  2. Approaches to answer the question – by whom, by which method, and their conclusions
  3. How is your attempt at answering the question different or the same from previous approaches
  4. Now what? – that is, what’s in it for the customer, the company, and how does the answer to the question enable innovation on behalf of the customer?

(via Amazon: How are the 6 page “narratives” structured in Jeff Bezos S-Team meetings? – Quora)

Sample Templates

  • None available (yet)

Best regards,
Michael Herman (Toronto)
Parallelspace Corporation
mwherman@parallelspace.net

Leave a comment

Filed under Uncategorized

Crossing the EA Chasm: Re-visioning ArchiMate 3.0 Elements as Adjectives [WIP]

COPYRIGHT © 2016-2017 by Michael Herman, Toronto Canada. All rights reserved.

[NOTE: This is a work-in-progress (WIP) placeholder for an article I plan to write …likely sooner rather than later …but there’s no specific schedule.]

Basic Concepts: Nouns and Adjectives

Referring to Figure 1 below, imagine that there are only a small number of concrete concepts in the ArchiMate language:

  • Model,
  • Concept

…and the remaining concepts are simply derivations of the one of these two Nouns: Model or Concept.

figure-1-top-level-hierarchy-of-archimate-concepts

Figure 1. Top-Level Hierarchy of ArchiMate Concepts (The Open Group)

Model and Concept become new Nouns in the next to-be-updated version of the ModelMate Information Architecture for ArchiMate.

The remaining concepts in Figure 1 and Figure 2 become Adjectives (i.e. abstract or virtual concepts) that modify or specialize the behavior of the target concept. The purpose of an Adjective (and more often a collection of Adjectives) is to support specialization of a Noun.

For example, in Figure 2 below, the box entitled “Capability” is a Concept which inherits the following Adjectives (specializations):

  • Element_ModelMate30_Parallelspace
  • BehaviorElement_ModelMate30_Parallelspace

figure-4-hierarchy-of-behavior-and-structure-elements

Figure 2. Hierarchy of Behavior and Structure Elements (The Open Group)

For a more elaborate example (see Figure 3 below), Business Role, Business Actor, and Business Collaboration are Nouns which inherit the following Adjectives:

  • Element_ModelMate30_Parallelspace
  • BusinessElement_ModelMate30_Parallelspace
  • InternalActiveStructureElement_ModelMate30_Parallelspace

figure-50-business-internal-active-structure-elements

Figure 3. Business Internal Active Structure Elements (The Open Group)

Windows Server Windows Service Example

TODO

1 Comment

Filed under Uncategorized

How do I model “X” using ArchiMate?

As a follow-on to a recent “How to I model X using ArchiMate” question in the LinkedIn ArchiMate group  (Modelling Blockchain technology), there are some standard questions that need to be answered before one can provide a good answer to a “How to I model X using ArchiMate” question:

  • In terms of level of detail, are you looking for a
    • Conceptual architecture view
    • Logical architecture view
    • Physical architecture view
    • Ecosystem view
  • Which architecture layers are you primarily interested in?
    • Corporate Strategy
    • Enterprise Architecture Strategy
    • Business Architecture
    • Application Architecture
    • Technology Architecture
    • Physical Architecture
    • Implementation and Migration Plan
    • …or, in the case of the Blockchain example, are you interested in a model of the entire ecosystem?

For example, at the highest level, are you interested in an ArchiMate representation of an entire ecosystem? …the Blockchain ecosystem, in this example.

firstpartner-blockchain-market-map_evaluation-v1-0-30-11-15-page-001

Figure 1. Blockchain Ecosystem (2016)

…or the following? …a conceptual ArchiMate model of the Blockchain protocol (which is the key technical essence or differentiator that Blockchain represents).

parallelspace-blockchain-procotol-archimate-1-0-1

Figure 2. Blockchain Protocol: Conceptual Architecture

…or something in between like the following process model (if represented in ArchiMate)? For example, the following diagram is a standard diagram used in a large number of Blockchain presentations.

how-blockchain-works-linkedin

Figure 3. “How Blockchain Works” Process Model

Best regards,
Michael Herman (Toronto)
Parallelspace Corporation
mwherman@parallelspace.net

*ArchiMate is a registered trademark of The Open Group.

2 Comments

Filed under Uncategorized

ArchiMate 3.0: What is the preferred way to model a Server Farm?

For the ArchiMate 3.0 experts: What is the preferred way to model a Server Farm given some of the new elements in ArchiMate 3.0?

In ArchiMate 2.1, a collection of nested Nodes was the most obvious solution.  What is the preferred approach using ArchiMate 3.0 to model Server Farms given a) Grouping is now a (an almost) first-class concept, and b) the new Technology Collaboration element. What is the best choice?

Here’s 2 examples: Server Farm A using Grouping and Server Farm B using a Technology Collaboration element.  I’ve used slightly different scenarios for each example but my assumption (hope) is that is shouldn’t make any difference.

Server Farm A using Grouping

server-farm-a-grouping

Server Farm B using a Technology Collaboration element

server-farm-b-technology-collaboration

What is the preferred way to model a Server Farm given the new elements in ArchiMate 3.0? a) Grouping, or b) the new Technology Collaboration element.  …or something else?  What are the pros and cons of your choice?

Add your answer to the Comments section.

Best regards,
Michael Herman (Toronto)
Parallelspace Corporation
mwherman@parallelspace.net

p.s. Below is a model for Server Farm C – using the Node aggregation approach we used with ArchiMate 2.1.

server-farm-c-node-aggregation

3 Comments

Filed under Uncategorized

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 😉

Leave a comment

Filed under Uncategorized