Technology Alignment from Within

IT and OT integration promotes a consolidated view of information management within an enterprise, which is a key element for that high-performance environment where every stakeholder/user has the right information, in the right format, and at the right time in order to make the best possible decision, with the least amount of effort. Steenstrup tells us this in the article, IT and Operational Technology Alignment Innovation Key Initiative Overview, and I am a firm believer of it. The technology organization must be aligned as to give decision makers the power to make optimal decisions with the least amount of effort, technology should enable them to do so, and it should provide power and give access to knowledge efficiently.

However, as Steenstrup describes, that is simply the end goal, but there are many other benefits when your technology organization is aligned, and acts as one:

1- There will be cost reduction opportunities in terms of future integration projects, the procurement of software and the management of its life cycle, cost of software licensing, external and internal costs of software support, and more.

2- Risk will be reduced, less malware intrusion and fewer internal errors will result from a more cohesive technology organization. This emanates from the enhancements bestowed upon cyber security when IT security resources are shared with OT staff in order to implement holistic security measures, and in other areas such as version control, patching and upgrades, which should happen in coordinated fashion.

3- Lastly, there’s also the fact that when standards are communicated and shared, and there is a platform in place where said standards can be accessed, then organizations will reduce risk and shorten project timelines and hybrid projects, that require both IT and OT involvement, will meet far fewer obstacles. This can be achieved by having an agreed upon approach where a common set of standards and architecture plans are shared and utilized.

So, how ready is your organization to facilitate this integration between Informational Technology and Operational Technology? As Steenstrup explains, a few factors should be considered to determine this.

1- Does senior management understand what it means to evolve OT systems against the cost and risk of not managing them correctly?

2- You must be clear as to what OT is from your organization’s point of view, this way you can identify which groups in your organization manage, use, own or should own OT processes.

3- Assess opportunities to push for the alignment we have been discussing, like a major change in technology platforms.

This was definitely a valuable article for me and it gave me a lot to think about. It is an important topic and every enterprise strives to make this assimilation/integration happen in various ways, and I believe it is definitively a work in progress that is never quite completed.


References


Steenstrup, Kristian. IT and Operational Technology Alignment Innovation Key Initiative Overview. Gartner. July 22nd, 2011.

Enterprise Architecture and the Need for EA Agility

What enterprise doesn’t need management and technology practices that improve its performance by enabling it to see holistic and integrated views of their strategic direction, business practices, information flows and technology resources? Without current and future enterprise views, it becomes hard to manage the transition from current state to the future operating state, while adding more duplication and disjuncture to existing systems.

Alignment within an enterprise leads to the optimization of the usage of resources. This is where EA comes in, it helps ensure enterprise activities are not disjointed and helps reduce duplication of processes and applications. It also leads to a complete approach to management, planning and documentation; creating aligned strategy and business driven views of the enterprise. EA also should help ensure that investments have a linkage to strategic goals and business outcomes are obtained in the most efficient manner, if your EA is not doing this for you, then it isn’t being effective (Bernard, 2012, Chapter 1).

How does EA promote this alignment exactly? It draws from accepted standards and promotes the use of non-proprietary commercial solutions, enhancing integration and allowing for the “plug and play” of components, promoting agility to address change (if your EA has shifted to allow for this). EA can ensure separate sub-architectures are not needed to reflect different levels of the enterprise and it will enable you to provide ongoing capability and coordinated views of the strategic direction of the enterprise, and in regards to the business services, information flows and resources. An effective EA allows decision makers to make optimal judgments by obtaining coordinated information. This capability is aided by the standard language and methodology that EA brings, which all stakeholders can speak, in alignment (Bernard, 2012, Chapter 3).

How do we know whether our EA practice is actually delivering on the items we have outlined? Defining and tracking EA business-value metrics (qualitative and quantitative) improves the value proposition and impact of EA efforts (Brand & Smith, 2018). Projects guided by EA principles, road-maps, guidance and standards can also be measured directly and indirectly. “The direct measure of the impact of standards is the number of exceptions or waivers that are granted during the architecture assurance process. The indirect measure of the impact of standards is the business outcomes” (Burke & Burton, 2017, p. 9).

So, we know what EA is, what it does or should do. However, why is EA not effective in every organization? And why is it perceived by many, including decision makers that I have interacted with, as cumbersome, slow, and counterproductive? That is perhaps a direct result of the traditional EA vs. the Outcome-Driven EA dilemma.

An Outcome-Driven EA allows us to directly address the business outcomes of highest priority to the enterprise by aligning deliverables to the business direction, and vision, and the highest value added deliverables. In contrast, the traditional EA is too focused on collecting the current state architecture, which generates large amounts of objects and relationships that do not have a direct linkage to business outcomes, which wastes time and resources. The Outcome-Driven EA follows a methodology that simplifies it's development by creating a stage plan that exclusively targets the delivery of stakeholder value. Lastly, measurable outcomes are relevant; we should seek observable change in key business performance metrics within a defined time-frame (Bernard, 2012, Chapter 4).

How does this get enforced? At the center of the Outcome-Driven EA is the architect, rather than documenting the current state endlessly, and “filling out” the traditional framework, they should focus on developing the EA by targeting a limited set of outcomes and framing deliverables that are directly linked to business outcomes and key business disruptions. The architect’s focus should be exclusively on the deliverables required to address the target business outcomes, which can be achieved by effectively executing the stage plan through the re-focused EA delivery life-cycle (Burke & Burton, 2017).

However, the traditional EA is not without merit, and components of it must be leveraged. The current view of the architecture is important since it provides a set of baseline artifacts that can be used for planning and decision making, as a reference. The current view of the enterprise helps clearly show associations, dependencies and performance gaps in the enterprise’s business requirements and current capabilities. We can also observe which resources are being used in which LOB (line of business) to support the achievement of their strategic goals (Bernard, 2012, Chapters 1, 3, 7). There is great value in capturing the current operating environment because resources may not be aligned to the strategic goals and business services that the enterprise wishes to target, furthermore, significant duplication in functions and tools may exist. Even a traditional framework will be able to help map how to close gaps between the current and future state by utilizing the information from the current view, like having the blue prints to a home. Additionally, in documenting the current view of the enterprise, performance gaps that were not visible before may emerge (Allega & Burton, 2018).

That being said, organizations should forego the traditional EA approach given the issues mentioned. Additionally, with the traditional approach, the architect’s focus is on completing the framework and “filling everything out”, leaving little room for innovation. Instead, organizations should streamline EA development and focus on deliverables that directly address the highest priority business outcomes (Burke & Burton, 2017). The best way to accomplish this is to integrate agile practices with your outcome-driven EA, by doing so leaders will embrace innovation and take advantage of digital technology by using the design capability of EA in order to harness the creativity and talent already in their organization, to help create optimal solutions. An agile EA will also drive digital innovation by using design thinking created by lean techniques (Blosch, Burton & Walker, 2017). Agile focuses on rapid testing of market opportunities, experience and engagement, as well as experimentation led by disruptive innovation and collaboration across partner ecosystems; it also focuses on outcomes and sees failures as an opportunity to learn. Lastly, from a technology perspective, this EA will use reusable components and solution-driven techniques (Blosch, Osmond & Norton, 2016). In short, the Agile, Outcome-Driven EA, will enable the enterprise to truly embrace the digital era and survive major disruptions, where traditional EA may not be up to the challenge and be seen as an impediment, as we discussed earlier.

The above guidance is solid, however, we must note that the impact of agile practices in your EA won't be as great without having an outcome driven EA that seeks to support the business strategy and objectives that are mapped to the main business disruptions that your organization is facing (Burke & Burton, 2017), this means you have to know what those are. The key is to focus on producing signature-ready deliverables that drive business change; using Agile is great but efforts must be focused on high value deliverables that are mapped to business objectives. Agile can speed up delivery on items but the focus should remain on deliverables that address the highest-priority business outcomes that help address key disruptions and concerns of key stakeholders. To this end, agile practices should be combined with a design capability that helps drive digital innovation which can maximize the creativity and talent within the organization to help create optimal solutions (Blosch, Burton & Walker, 2017). If the aforementioned is not accomplished by using the EA, or rather, if the EA does not facilitate the accomplishment of said strategic goals and helps address business disruption, then the business will find ways to "address" those concerns by working around the EA, and the vicious cycle of shadow IT, duplication of systems, convoluted processes, lack of governance, etc. will inevitably ensue.

References

Allega, P., Burton, B. (2018). Massively Disruptive Events Require a Nonlinear Approach to Enterprise Architecture. Gartner. February.

Bernard, S. A. (2012). An introduction to enterprise architecture. Chapters 1, 3, 4, 7. AuthorHouse.

Blosch, M., Burton, B., Walker, M. (2017). Build the Design Capability of Your EA Practice to Drive Digital Innovation. Gartner. February.

Blosch, M., Osmond, N., Norton, D. (2016). Enterprise Architects Combine Design Thinking, Lean Startup and Agile to Drive Digital Innovation. Gartner. February.

Brand, S., Smith, M. (2018). EA Business-Value Metrics You Must Have Today. Gartner. May.

Burke, B., Burton, B. (2017). Stage Planning a Business-Outcome-Driven Enterprise Architecture. Gartner. p. 9. March.

Cloud Security – A Reflection

The Gartner article by Jae Heiser, Analyze the Risk Dimensions of Cloud and SaaS Computing, was really relevant for me in the topic of Cloud security and the different implications of IaaS, PaaS and SaaS models from a risk management perspective. As more vendors move their solutions to the Cloud, forcing customers to adopt some sort of Cloud model, we are left struggling to figure out how security looks; it is certainly one of the toughest things to deal with in this space.

Heiser correctly points out that analyzing risks, when it comes to cloud computing, becomes complex given a lack of best practices on the method and content of a cloud services risk assessment. This is driven by the lack of transparency presented by service provides, particularly in a SaaS model. Under normal circumstances, where the organization has control, there is an expectation that the systems that are being evaluated are well proven and well understood, meaning we know where all the layers are located and privileged users are identifiable and supervised in many ways. When it comes to SaaS solutions, the system administrators are not known and many different layers of the architecture, like the services, network, the storage, the servers, and in many ways even the application, are black boxes, as far as the client is concerned. As Heiser notes, this concern is not so prevalent with an IaaS model, given customers control a lot more in terms of the data, the application, the virtual machines and they are actually responsible for monitoring and auditing to a large extent, and have the required access to perform such activities. Lastly, with PaaS, there is far more shared responsibility between the customer and the provider given where the security controls are located.

Again, with SaaS, the provider is responsible for pretty much all of the security functionality, the monitoring, and incident response. All this means is that you as a customer have minimal ability to add controls and other security mechanisms outside of functionality that is native to the application, as Heiser notes. Do you want to set up a custom alert when a financial period is opened or a user creates an invoice over a specified threshold? You better hope the application can do that out of the box, because you can’t extend it. Also with SaaS, design and build of any application related functionality is a black box for customers, and you may simply receive and email with the latest updates that will be released for your application the following month. Without this transparency there can be no expectation that functionality will remain the same, meaning we have to take into account security testing in the time allotted to us as users, in order to test whatever controls we do have access to before the updates get rolled out to your Production environment.

One important point Heiser talks about, which many don’t think about, is that often times your cloud providers are themselves a customer of an additional provider. So basically, your provider may own and support the application, but they may be using another provider for the infrastructure, the storage, etc. This is called a nested hosting arrangement, and it really complicates security even further. Everything that has been mentioned to this point has really been assuming that your SaaS application is fully supported by one vendor, but the risks are compounded, and the complexity increases many times over, when nested hosting is in place. Basically, you need to conduct a risk assessment of each and every provider involved in each layer of that cloud application (this may apply to more than just SaaS).

As Heiser reinforces, oftentimes there’s really nothing you can do given the lack of transparency in many areas, so you have to rely on your contract serving as a mechanism that ensures appropriate levels of security and service level expectations, at the risk of transparency and real control. This of course is all depending upon whether the legal system will enforce penalties for noncompliance and to what degree. Overall, it is very clear that security in the cloud is a behemoth of a problem, and it involves everything from risk assessment of your providers to controls, to auditing, to monitoring, and everything you can think of that’s security related and you were able to do in your On-Prem environments. It is worth noting that many vendors will work with you and provide evidence of whatever controls you ask of them, and you should, and they should be able to produce proof, also, certain providers have different tools that handle security within their suite of Cloud tools, which you can leverage to satisfy some additional controls.

References

Heiser, Jay. Analyze the Risk Dimensions of Cloud and SaaS Computing. Gartner. March 15^th, 2013.