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.

Advertisements

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 4 – Stop Concentrating on ETA!

This short Gartner article (G00160635) is something everyone doing, or who thinks they are doing, enterprise architecture should read.  I have found in my career a troubling tendency of EA professionals to all to often focus their energies on the technology aspect of enterprise architecture.  The Gartner article they advise clients to not work primarily on enterprise technology architecture and ignore the other aspects such as business and information architecture.

In my opinion, there are a couple of factors at play here.  Many, not all, EA practitioners have focused so much on technology in their careers they are more comfortable in that arena and therefor focus much of their energies.  This is very short sighted, since it elevates technology to a place where it is more valued than the work it supports.  Technology is just a tool that a business can use to achieve their end goal, but it is not the end goal.  Instead EA practitioners should learn to focus less on the technology and more on working with state holders to identify the desired capabilities that they need to achieve, and then helping them develop the requirements necessary for the business to achieve those capabilities.

I remember in EA 872 Dr. Cameron was strongly of the opinion that the Enterprise Architect of an organization should not report to the CIO. All too often, I see EA’s who focus more on ETA and less on other aspects of enterprise architecture.  And reporting directly to the CIO rather say the CEO, leaves them in the position to be more technology rather than business centric.  But pulling the EA position from under the CIO allows the EA to become more attuned to the business rather than being just another IT function.

Topic 4 – Enterprise Architecture to prevent insider data breaches

I saw an article this past week posted on the LinkedIn Enterprise Architecture Forum(https://www.linkedin.com/groups/36248/36248-6189836445927100419) asking if Enterprise Architecture could have been used to prevent the latest incident of classified data being removed from the NSA.

I’d argue that in the aftermath of the Edward Snowden disclosures and the director of the NSA grilling before the Senate Judiciary Committee last December, I would say they already have. The Snowden disclosures changed the procedures for handling classified data by both the intelligence and defense communities as well as their contractors.  Rules that were implemented were the “Two Person Rule”, which required two people to perform a critical operation such as downloading files.  Additionally, the use of encryption has been increased.  For example, users can encrypt their home directories, which even when backed up to a server would prevent a systems administrator (Snowden) from viewing their files.

The IC and DoD communities have also instituted physical access controls such as disabling USB ports, DVD drives, and other removable media. Software has been installed on servers, workstations, and VM’s to determine the movement of files by users across file systems and media.

In short, security has been increased across the both government and contractors to increase accountability and provide security at a highly granular level.  In the article on LinkedIn, the author links to an article in Federal Computer Week (https://fcw.com/articles/2016/10/05/fbi-booz-contractor-arrest.aspx) that gives brief details of the arrest of a contractor for taking classified data from the NSA.  If you carefully read the article there is no mention of a timeline, so it could have happened prior to the NSA’s implementation of the “Two person” rule.  In addition, the article mentions that some of the data taken was in hard copy (paper) form, which is extremely difficult to protect against.

 

Topic 4 – Enterprise Architects should focus on Business Capabilities rather than technology

I am not anti-technology, but let me say that customers don’t pay businesses for the brilliant implementation of their technology solutions.  They pay them for the work they produce.  But too often EA’s and IT people lose track of their core reason for being, to provide the architecture and supporting infrastructure so a business can produce goods and services people want to buy.  Technology is only worthwhile if it allows you to achieve your business objectives.

In their Cutter Consortium paper “The Business Capability Map: The Rosetta Stone of Business/IT Alignment” (Cutter Consortium, 2011), authors William Ulrich and Michael Rosen argue that business capabilities provide a new language abstraction that supports Business/IT Transformation. By focusing on the “what” a business does, and not the how (i.e., the complexities of the business processes and/or IT solutions), Business Capabilities are useful when framing the benefits of EA-based initiatives for executives.  The paper makes the point that mapping capabilities to business core functions, supporting capabilities (HR, legal and procurement) and their value added capabilities (IT, customer management, account management, etc.). Essentially, the map allows the business to decompose the services a business provides and allowing management and employees to view the structure of the business.

Think of the capability map as a blueprint for displaying the capabilities of a business. It is important to keep in mind that this maps displays the business as opposed to the enterprise since the business will likely extend past the enterprise. For example, if a business outsources a number of its capabilities this would be included within the business but out of scope of the enterprise.

It is important for a business to have one map for its business as opposed to separate maps for each business unit. With one map each unit within the business will map their capabilities to the larger capabilities of the entire business. These business units will than add their contributions to and leverage this one map.

As it relates to EA, one of the values of the mapping the capabilities to the business architecture, is that the business-to-business and business-to-IT capabilities provide much of the analysis associated with the business and IT transformations. This allows for greater decomposition of these activities even to the point where the activities can be decomposed down to business processes.