Topic 7 – Internet of Things in the Enterprise (Revisited)

Not long ago I wrote about IoT and said that the enterprise architect should take the lead role in architecting the insertion and use of these devices.  Just to recap; the number of connected devices has been estimated to be at 5 billion now and growing to over 38 billion by 2020. These IoT include smart light bulbs, thermostats, air cleaners and refrigerators (to name just a few).  In addition to the home, these devices are finding their way into the enterprise at an increasing pace.

While all this may be good, these devices will require “care and feeding” and it will be up to the enterprise architect to sit down with the business organization and IT to determine how best to handle these devices.  After all its not simply that they are connected to an organizations network, these devices produce data that must be stored and analyzed.  Questions come up about how will this data be used by the business units to create value add to the business or to the customers.  It is critical that the enterprise architecture team begin (if they have not already done so) to sit down with the management and IT and chart out the need, the use and the cost (vs. benefit) these devices will add before the first rollout.

I recently witnessed problems a sponsor was having on an enterprise we had help them design.  They were complaining of slow downs across their network and asked us to take a look.  After reviewing there enterprise we could not figure it out, so we agreed to take a site tour.  The first day we looked around and did not see anything abnormal. It was not until we put an analyzer on their network that we saw all this traffic.  As we dug down, we found a number of devices that we had no idea what they were.  Turns out that their IT organization found some IoT devices to monitor environmental conditions in the many, many buildings this sponsor had under one geographic area.  Due to some misconfigurations these devices were sending out large volumes of data that was dragging down their network.  These devices were introduced without proper controls or due diligence by their IT organization at the request of their building services group.  Needless to say the business management people were not happy.

With IoT, and other technologies for that matter, the enterprise architect can help guide a business to the proper use and deployment of new technologies. The EA’s skills position them well to handle the insertion of technologies that could be either beneficial or detrimental to the enterprise.

Topic 7 – Mini book review

A few weeks ago I started reading a book called “Model-Based System Architecture” by T. Weilkiens, J. Lamm, S. Roth and M. Walker.  The book is geared toward the system architect, but much of what is discussed is also relevant to the enterprise architect. The scope of the book is how to use model-based systems architecture to achieve the goals of developing a systems architecture that is already established or planned. The book uses as its core modeling language SysML to build the architecture descriptions, however, the concepts are independent of SysML and could be performed with other modeling languages.

The book goes into the benefits of systems architecture on system development such as shorter development and production cycles.  How to develop the base architecture, elicit use cases and develop requirements are covered as well as the model structure. The book also spends a good amount of time on examining how model-based systems architecture can be used to ensure that things like stakeholder analysis and trade studies can be performed and than presented to people who may not be versed in the nuances of the model. And while using models as the basis for the architecture makes sense, this book also goes into the “soft” skills that a good architect needs to possess. Besides the obvious skill of communication, which everyone mentions, the authors talk about the ability to abstract stakeholder concerns, use cases, requirements and desired capabilities and created abstract views in the models that link these things together into a larger picture (or series of views).

The book also spends time looking at some concrete process steps needed in developing a systems architecture.  Some of these processes where ideas the authors put out, but others such as the FAS (Functional Architectures for Systems) method which comes from Europe. The FAS method looks at identifying functional elements of the system and decomposing them into a hierarchical functional structure. In other words, developing a hierarchical structure of the functions the system or enterprise should be performing. This is done so that the stakeholder concerns, use cases and requirements can be mapped to those functions which would allow the architect to extract the components necessary to design the system.  Other systems architectural processes was their look at how Agile methods could be used in systems architecture development.

The book goes into architectural frameworks and well as a look at case studies from the authors experiences.  I found that while the book has a very technical outlook in how to use model-based systems architecture, it does not disregard the need to include the soft skills as well as the overall organizational view of how a system fits into the structure of an organization.

T. Weilkiens, J. Lamm, S. Roth and M. Walker. 2015. Model-Based System Architecture. John Wiley & Sons, Inc.

Topic 7 – Institutionalizing Innovation

The organization I work for is the largest University Affiliated Research Center’s (UARC) in the United States.  I has had more than 70 years of innovation in service to our nation.  It encourages people to think outside the box and propose new ideas.  This worked well for most of those 70 years, but the ways of proposing these ideas was rather slow and at times difficult.

About three years ago the Laboratory embarked on new ways to spur creativity and innovation.  They did this by establishing innovation spaces, mini grants, and centers of excellence.  I’ll first describe the innovation spaces.

The innovation spaces include one area called “Central Spark”. This area is available for staff members to pursue endeavors for both personal and sponsor related work.  The facility includes several laser etching and engraving machines, electronic breadboards, numerous 3D printers, a CNC machine, metal lathe, milling machine and various tools such are drill presses, soldering irons, and hand tools.  In addition, there are several centers of competency such as modeling and simulation, design thinking, and Agile resources.

The second center is called the Intelligent Systems Center which tries to translate research into machine learning, autonomy, robotics and applied neuroscience into capabilities  to address U.S. government challenges.

The third area is ICEland (Instrument, Concept & Evaluation).  These labs are set up to allow the rapid evaluation of new concepts using some of the latest electronic tools.  Some of the tools include devices like advanced biological sensors, high speed cameras, sophisticated networking tools and other devices.

Finally, the Lab has setup an entirely revised grant structure that allows staff members to pitch ideas for research funding and have them voted on by a group of their peers rather than being forced through a series of committees presided over by a select few.  If these smaller grants have the ability to demonstrate value, they can then be expanded for a second phase of funding.  At this point the idea is to engage more people from different departments who can help expand the idea and add value.

New this year is a category of funding dedicated to people who wish study what work has been done by people well outside the traditional academic arena.  This funding will allow staff members to travel to conferences and events to meet people whose prime work fall outside the traditional DoD interests, but might still be relevant. Some funds are also available to allow staff members to travel to some of these conferences and present papers even through the conference is unrelated to the type of work we normally perform.

Through all these means the Lab is really trying to encourage staff members to think outside the box and explore ideas that interest them and possibly provide value to our work.

Topic 6 – Modeling the Enterprise

I am very interested in modeling languages as they apply to my work in systems engineering and enterprise architecture.  Because of this interest I am constantly reviewing literature to see what people have done.  I recently came across an article written in 2011 entitled “Enterprise Modeling and Simulation within Enterprise Engineering.” in the Journal of Enterprise Transformation.

The author of this article was proposing to model the enterprise architecture, including the business architecture and business processes with discrete event simulation tools such as Arena, ExtendSim, or STELLA. While this possibly sounds compelling, it could also turn out to be an interesting, but complex, endeavor that would need to be undertaken with strict bounds regarding what and how much to model. Additionally, the use cases for such an approach would be limited to businesses which could benefit from tightly controlling their processes such as supply chain, logistics, manufacturing, and hospitals. Although simulation tools are used in business and financial markets, the use of discrete event simulation tools would probably not be as beneficial as it would to the markets mentioned previously.  At least these were my thoughts going into the paper.

Upon reading the paper, I found that not only were my initial thoughts verified, the author stated that the week link is the lack of a conceptual model. This should be a “no brainer” to most people in either enterprise architecture, that without a conceptual model you cannot develop a meaningful simulation.

Barjis, J., 2011. Enterprise Modeling and Simulation Within Enterprise Engineering. Journal of Enterprise Transformation. Taylor & Francis.

Topic 6 – Confusion between Measures of Effectiveness and Measure of Performance

I was in a discussion with a sponsor recently in a project meeting about the meaning and usage of MOE (Measure of Effectiveness) and MOP (Measure of Performance). I just wanted to share some thoughts about this. The difficulty is that with these terms the definitions can vary widely from source to source such that what one will call an MOE another might call an MOP. And at a certain level of decomposition the MOE and MOP might look pretty much the same.  In my opinion, the keys to thinking about these definitions are the words themselves.

I will use the term “thing” below because system, system of system, complex system, etc. merely obfuscate the concepts by overlaying other disagreements about what certain “system” terms mean.  And “system” is not pertinent to the MOE/MOP discussion, though we usually apply them to systems.

Measure of Effectiveness – this implies that whatever is being measured is telling one whether or not the “thing” met some success criteria related to the problem it was to address.  Was this a “good” solution to the problem? Was this a better solution to the problem than another solution?  The point being that one remains focused in the problem space, solving the problem, measuring the problem.   This is why the literature for MOEs often refers to them as being mission-oriented.  The Problem Space is where one discusses what the “thing” will do/accomplish, not how it does it.

MOEs are not necessarily composed of a mathematical relationship to MOPs.  In fact, frequently they are not.  If you read the Sproles articles referenced below, he has an anecdote about the reduction of pollution in an Australian river.  The MOPs were ppms of different toxins in the river; the MOE was that the mayor of the town was willing to swim in the river. It might be an apocryphal story, but it illustrates a situation where the MOE was not just an accumulation of the MOPs.

In fact, this is one good reason to do so much modeling and simulation.  It is because there are no good ways of combining system MOPs to get MOEs.  If there were, all of the problems we solve would have closed form solutions.  Measures can be tiered when dealing with complex capabilities. For example, a weapon system could have a high level measure of “survivability” that decomposes into more granular measures of “threat exposure” and “threat effectiveness”. These can be good metrics, but given all of those what was the overall goal for “mission success”?  How did you know you were done?  Or the solution was good enough?  In the context of the whole simulation, what was the measure that showed one result was better than another.

Measures of Performance – these on the other hand are found in the Solution Space.  They are typically intrinsic attributes of the thing that describes how well it performs a function or set of functions.  Performing a function well does not necessarily mean that the thing was more effective at solving the problem the thing was created to address.

In the Problem Space we often discuss the purpose (the mission) of the thing.  The Measure of Effectiveness then evaluates the things ability to meet the needs of the mission in the context of the problem and the mission, and not the performance of the thing.

In the Solution Space, an instance of the “thing” (multiple different instances of the “thing” can be conceived and created) is created to address the problem and or mission.  Measures of Performance are what describes attributes of the thing but not necessarily how well it addresses the problem/mission.

The Problem Space is frequently decomposed into discrete elements that are generally called something like mission functions.  These are broad sets of activities that elaborate what must be done to accomplish the mission.  MOEs measure these activities.  In the Solution space there also functions (these are the solution, or system, functions).  These are not the same functions as described in the Problem Space.  MOPs measure these.  Example: SpaceX launchs a supply rocket to ISS.  One mission function, after launch and clearing the tower, could be something like “Ascend to Orbit”.  A complimentary system function could be something like “Produce Thrust”.  A MOE might be probability of achieving correct orbit.  An MOP might be the specific impulse of the rocket engine.

Sproles, N., Coming to Grips with Measures of Effectiveness, Systems Engineering Journal, Vol. 3, No. 1, 2000, pp. 50-58

Sproles, N., Formulating Measures of Effectiveness, Systems Engineering Journal, Vol. 5, No. 4, 2002, pp. 253-263

Sproles, N., The Difficult Problem of Establishing Measures of Effectiveness for Command and Control; A Systems Engineering Perspective, Systems Engineering Journal, Vol. 4, No. 2, 2001, pp. 145-155

Topic 6 – Archimate Overview

I was recently asked to put together an overview of Archimate to present to an audience of systems engineers and enterprise architects.  I have long been interested in modeling languages, so this was right up my alley.  I’d like to share some of what I put together for the readers not familiar with Archimate.  Please not this was put together before I had time to digest the newly released ArchiMate 3.0 specification.

ArchiMate is an open and independent enterprise architecture modeling language maintained by The Open Group. It is partially based on the IEEE 1471 standard. The language is used to describe, analysis and show a visual representation of the architecture within the enterprise and across the various business domains. Because ArchiMate is billed as an enterprise architecture language we are spending more time reviewing it.

ArchiMate differs from UML and BPMN in that it is used to describe the relationships between concepts in different architecture domains. UML is for modeling more detailed concepts such as software products and BPMN is used for modeling business processes.

ArchiMate uses the concepts of layers, services, and core elements. The higher layers make use of the services provided by the lower layers. So in other words, the services flow from the bottom up. There are three main layers:

  • Business Layer: Deals with business processes, services and the functions of business units. This layer offers its products and services to external customers, which are in turn used in the organization by “business actors and roles.”
  • Application Layer: Deals with software applications that support the business and application services which are realized by software applications.
  • Technology Layer: Offers infrastructure services (processing, storage, network communications) needed to run applications, realized by computer and communication hardware and system software3.

Each of these layers gets further divided into sub-layers. For example, the business layer could have a secondary layer supporting business processes.   The application layer maybe sub-divided into end-user applications that might make use of services that support applications.

And each of these three layers has three core element types: Passive structure, Behavior, and Active structure.

  • Active Structure Elements are entities capable of performing behavior.
  • Behavior Elements are units of activity performed by one or more Active Structure Elements.
  • Passive Structure Elements are elements which Active Structure Elements perform behavior.

The ArchiMate 2.0 specification adds two more extensions: Motivation and Implementation & Migrations (Figure 1).

  • Motivation models the elements that “motivate” enterprise design and operation. Part of its concepts are: stakeholder, driver, assessment, goal, requirement and principle.
  • Implementation & Migration allow for the models to implement all aspects of EA, as well as migration between generations of implemented architectures. It’s concepts include: work package deliverable, plateau and gap.


Figure 1. Archimate 2.0 Layers

While ArchiMate is an important standard, it is not without its criticisms for lacking such things are capability mapping, ambiguity of concepts (multiple uses of the same concept) and a lack of execution semantics5. Additionally, ArchiMate is criticized for having morphed from a general purpose EA language to an overly IT centric language.

Even more importantly, ArchiMate does not provide any validation means of the models with respect to their correctness, consistency, completeness or comprehension. While languages such as UML and SysML provide validation mechanisms of their models through hooks into simulation tools, no such pathway exists in ArchiMate.

An additional problem with ArchiMate is that it’s support in tools varies from vendor to vendor and does not appear to be as consistent as languages standards supported by the Object Management Group (OMG). There is some talk about The Open Group and OMG working together to link ArchiMate with UML, however at this time there seems to be very little progress on that front.


Topic 5 – (un) Successful Enterprise Architecture

In my current job as a systems engineer, I have had numerous opportunities to review case studies of successes and failures within that discipline.  So I wanted to review similar scholarly articles about enterprise architecture.  This is where I was surprised to find far fewer case studies than I would have thought.  And the overwhelming majority were very positive.  Surely, not every implementation of EA is positive.  There must be some documented failures.

Maybe organizations who fail at EA don’t want to publicly proclaim their failure?  After all, it has to be easier to hide a failed EA implementation than a failed engineering project.  I am however, willing to admit that maybe it was just my failure in searching for failures.

This leads to my next thought, of what makes for a good implementation of EA?  To this I would add a short list, which is likely up for debate.

  1. Accurate and descriptive models. Enterprises are complex organizations that need descriptive models to organize the relevant aspects of the actual parts or behaviors. They also need prescriptive models that describe how to build other things to carry out these behaviors or tasks.
  2. Business focus. The architecture needs to be inclusive of the business view not the technology.  The technology is there to support the business not the other way around.
  3. Collaboration.  The architecture must support collaboration between the stakeholders from the C-suite, department managers, team leaders and individual employees. Buy in from top to bottom is necessary to a successful implementation.
  4. Focus on outcomes.  The architecture must be tied to business strategy.  Implementing architecture without the focus on achieving the desired business outcomes will lead to something more academically oriented than business oriented.