This weeks topic was security architecture. In my organization and the organizations that we support, security has always been important. But in the past few years, security architecture has become a well planned discipline, that is much more proactive than reactive. Security is now being treated like an important component to the overall enterprise architecture, like business and application architecture, rather than an after thought.
My organization was recently working with a sponsor to help them re-engineer their current enterprise. Not surprisingly, security was a big concern of theirs. My organizations core competency is systems engineering, so our approach is to view the enterprise as a sum of its parts rather than various entities that need to be bolted together. I find that there is much overlap been the systems engineering and enterprise architecture disciplines, as the focus is on integrating sub-systems and systems together.
After our group examined their currently deployed enterprise architecture and interviewed their various stakeholders, we were able to develop a conceptual design for a new architecture that allowed for a much tighter integration of their application, infrastructure and security operations than what is currently existing. The end goal is to not only create better overall security, but to make that security less of a foreground task that end users have to endure and much more of a background task that they hardly notice. Yet all the while providing much greater security for the organization than what previously exists.
Recently I was working with a sponsor to help them create a system architecture for their enterprise. The program is very large and we needed to capture their current (“as-is”) enterprise. As I and my co-workers were touring one of their facilities, I kept seeing all of these devices (smart thermostats, motion activated lights, security equipment, etc). Knowing that they connected to either a wired or wireless network, I couldn’t help but think about the impact these devices would have on their infrastructure. When I brought this up to our sponsor, they seemed generally perplexed and assured us that these devices have no impact on their infrastructure.
I can’t help but think that our sponsor is not unique either in their view of these devices impact on their network nor in the fact that the use of these devices will only grow with time. In fact a recent article published by Juniper Research estimates that by 2020 the number of “Internet of Things” devices will triple to 38 billion. This has the potential to negatively impact an enterprise if not carefully planned for.
These Internet of Things devices are typically connected to some network, but what about the data they generate? Typically these fall into silos that don’t talk or share data between each other. This fragmented data, while still useful, does not provide the level of insight needed to justify the large resource in an IoT strategy.
It’s at this point, I believe, that Enterprise Architecture can help. Enterprise Architecture can use this interconnectivity to group these devices and measure some of the data, to form new business models and uses. These devices than go from being a series of “things” to being a system of things.
The Enterprise Architects are well positioned to be able to discuss how to leverage these collections of “things” with the business and IT leaders. And at the same time work with the data and security management structure to ensure that risks are mitigated while focusing on new opportunities.
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.
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.
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.
Several of the readings on data architecture, Gartner’s “Managing Information as ans Asset” and Forrester Research’s “Simplifying Information Architecture”, provided great insight into how businesses could better align their information architecture with their business strategy. I found both articles relevant as I have seen both internally within my organization and with our sponsors a disconnect between business strategy and value and information. It is my opinion that this is an area where many enterprise architects struggle.
Many of the sponsors I work with, are quick to say that their information is their most valuable asset (forget the people). The problem with this is that not every piece of information has the same value to the business. Working with primarily DoD sponsors, I find that many of these people understand that some information is more valuable to the business than other information, but they tend to impose guidelines on the their information architecture that assumes all information has the same value. Obviously there are a number of problems with this view. As Gartner points out you need to determine the value of your data and its impact to the organization, risk, decisions, and business. Failure to perform this analysis often results in numerous problems. For example, truly not all information is of the same value, however, if it is all protected and maintained to the same standards, this often taxes the resources available to store and manage the data. We had one sponsor who required a large computational grid for engineering simulations. But their data management was all within the confines on one particular storage architecture that was not designed to handle the outputs this computational grid could produce. The solution was to upgrade the storage for this grid based around the specific use case of the engineering needs. What happened, was the sponsor thought all the rest of their organization needed this upgrade too. There were not enough funds to handle all this work and only parts got implemented with the rest phased in over the years.
These types of failures have far less to do with the skills of the data architects, but of the internal politics of the organization.
I am a strong proponent of modeling for all aspects of system development. One of the most important aspects of modeling, in my opinion, is to capture the “as-is” environment. Often customers or sponsors have existing systems not green fields. While most of my work has been in the systems arena, it has expanded slowly to include the enterprise architecture.
One of the first tasks we have done is to document the existing “as-is” architecture. What I am seeing when we do this, are data architectures that are sub-optimal at best. That said, you can’t make improvements to the data architecture from just your models. Unfortunately, non-technical aspects such as the governance, usage, and operational tend to be where most of these battles are fought.
The soft skills of determining, and enforcing, who controls and administers the data, storage length and archiving, data security and who controls what, are some of the biggest areas of challenge (or contention) that I have encountered. Once these and other concerns are addressed it is then possible to move forward with a “to-be” model.