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.

"The Case Against Cloud Computing" - A Reflection

The topic of the "Cloud" was definitely a hot one back when Bernard Golden wrote a series, named The Case Against Cloud Computing, in regards to the reasons enterprise architects were reluctant to embrace cloud computing, and it has definitely escalated since then.

Coming from a background of enterprise software, particularly ERP systems, and related financial applications, like tax engines and early payment discounting software, etc, I have been able to observe the rapid evolution of "the cloud", and thus the evolution of the barriers to cloud adoption is of interest to me.

In reading Golden’s articles on the topic, we can see that most architects were very preoccupied with frankly, the basics. For example, how do we get from point A to point B, how do we migrate the stuff we have On-Prem to the cloud without having to redesign how everything works. Then we had security, it was argued that cloud providers essentially weren’t competent enough to handle the client's data they way they could themselves. Golden also states that one of the main concerns was that Amazon’s core business wasn’t that of Cloud computing, so folks had a difficult time entrusting their data to them, in fear all the regulations that applied to their industry wouldn’t be followed and then also the fact that control would be lost to a large extent and therefore security would be compromised as a result.

There were other concerns such as the dependency on an outside vendor and also the fact that compliance measures couldn’t be properly enforced as a result. In essence though, security, control and “how do we get there”, seemed to be the biggest areas of concern, as Golden was able to compile and reflect upon from peers around the industry.

In the spirit of the 10 year challenge that has taken over social media, these articles were published in 2009; let’s look at how these pain points hold up today and whether others have surfaced.

Being immersed into this field for the past couple of years I can say that there have been definite improvements in the area of “how do we get there”. Most big vendors now have several migration plans that get you from your On-Prem solution to some sort of cloud offering, be it SaaS or IaaS, and they have dedicated staff and implementors that work with you to make it happen. So this is definitely a lot less of a concern, even for big ERP’s like Oracle EBS, since vendors have come up with “on boarding” strategies and assessments of your current state and how to get you there. These of course aren’t perfect, especially if you have super complex existing environments, but the road is definitely a lot less muddy presently.

In terms of security and the expertise of the vendor, well, we definitely can say that Cloud computing is one of Amazon’s core competencies now… and they are not alone, Oracle and Microsoft have very strong offerings and some of the top talent and best practices in terms of securing your data. This is especially appealing if you aren’t an “IT” company and your core competency lies elsewhere.

In terms of Infrastructure as a service, it can be said that the main challenge I and others have observed is that of performance and reliability as a factor of cost. Can you get the same service level expectation and for how much, versus keeping that solution On-Prem. You also definitely lose a lot of control in terms of when maintenance activities are performed and how long you lose access to the various systems (more so with a SaaS model). In terms of software as a service, the biggest pain point is the functionality and losing the ability to customize that application to fit your business needs. If you are going to a SaaS solution from a highly customized On-Prem suite of solutions, or solution, then big changes to your business processes will have to ensue, as you won’t be able to customize that application(s).

While great strides have been made in the Cloud space, there is something else that isn’t really a barrier, more so an annoyance, and that is that many vendors are aggressively migrating their offerings to the cloud and giving you very little options in that space, in some cases where it would make sense to have an On-Prem solution or an IaaS offering. Instead, you will see that the vendor only offers a SaaS flavor of that product you want, and that is definitely a negative in some regards. If anything truly negative can be said about the Cloud era, especially in the Enterprise Software space, which has long lasting effects and probably cannot be mitigated, is that the customer will lose their ability to choose how they want to play the game.

However, as Larry Hawes notes on his Network of Services article, it will be beneficial to think of enterprise software as a “network of functionality that helps all constituents of the business achieve their objectives” and that architects should think in “networked business terms and treat software functionality like networked nodes that may be fluently, even dynamically, related to each other”. I believe cloud computing can and is helping achieve that network of functionality he describes and helping achieve a more fluent relationship between systems by many measures, such as standardizing that “middleware” aspect of data communication and translation by essentially forcing the use of API’s and removing a lot of the complexity of the past that could ensue in proprietary environments.

In conclusion, the Cloud had some barriers and pain points 10 years ago which remain today but have evolved into different issues in the same category. Additionally, new issues and barriers have emerged and need to be mitigated, but the trend is undeniable and unstoppable in many cases.

References

Golden, B. (2009, January 22). The Case Against Cloud Computing, Part One. Retrieved January 15, 2019, from https://www.cio.com/article/2431187/cloud-computing/the-case-against-cloud-computing--part-one.html

Golden, B. (2009, January 29). The Case Against Cloud Computing, Part Two. Retrieved January 15, 2019, from https://www.cio.com/article/2431044/cloud-computing/the-case-against-cloud-computing--part-two.html

Hawes, L. (2012, March 15). Enterprise Software Architecture: A Network of Services, Not a Layered Stack. Retrieved from https://www.forbes.com/sites/larryhawes/2012/03/14/enterprise-software-architecture-a-network-of-services-not-a-layered-stack/#5c37fdb07229

Digital Disruption

Digital disruption is all around us; it has been for a while and continues to leave its mark. Depending on which industry you are working at you will see the impact of the digital era and its disruption more clearly, and that is highly dependent upon the business and operating model of your enterprise. Olanrewaju and Willmott speak in regards to this in their article, Finding your Digital Sweet Spot. This article speaks in regards to the potential impact of digital and how it varies by industry.

The article covers three clusters of industries that face varying levels of change in regards to digital transformation. There are the long-term multi-channel industries, like grocery retailing and apparel, which despite innovations in that sector are not as heavily impacted, in terms of digital, at least as compared to the “eye of the storm” industries, such as retail banking and mobile telecommunications, which are highly susceptible to digital disruption, due to having a cost base which is largely focused on processing and servicing. Then the authors speak about the “new digital normal” industries, which have completed several rounds of digital disruption, like music retailing, airlines and hotels. This article is a good exercise in terms of making you think where your industry finds itself in terms of digital disruption and how much change is expected in those sectors as a factor of that disruption.

One thing is certain, digital can reshape all aspects of any modern enterprise and that is why the modern Enterprise Architect must ensure that the EA (Enterprise Architecture), instead of being an agent of change, that it becomes an architect of change, as Bloomberg points out. The typical EA and the outdated frameworks will not be agile enough to support the digital goals of the business, and depending of the industry, that business may not be able to survive without fast adoption of the changes that must occur as a factor of digital disruption.

I think an important aspect of allowing the digital transformation to take place is to, as Larry Hawes notes on his Network of Services article, think of enterprise software, and the stack, as a “network of functionality that helps all constituents of the business achieve their objectives”, which will in turn allow software functionality in the enterprise to flow dynamically and fluently, better serving the different lines of business all across the enterprise. The old layered and hierarchical approaches will not be able to allow for digital transformation to occur as swiftly as it should in order to combat digital disruption, especially if you find yourself in the “eye of the digital storm”, as far as your industry goes.

References

Bloomberg, J. (2016, June 16). Change As Core Competency: Transforming The Role Of The Enterprise Architect. Retrieved from https://www.forbes.com/sites/jasonbloomberg/2016/06/16/change-as-core-competency-transforming-the-role-of-the-enterprise-architect/#67240731164a

Hawes, L. (2012, March 15). Enterprise Software Architecture: A Network of Services, Not a Layered Stack. Retrieved from https://www.forbes.com/sites/larryhawes/2012/03/14/enterprise-software-architecture-a-network-of-services-not-a-layered-stack/#5c37fdb07229

Olanrewaju, T., & Willmott, P. (n.d.). Finding your digital sweet spot. Retrieved from https://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/finding-your-digital-sweet-spot.

E-Business Suite Support Analyzer Bundle Menu Tool and Automatically Updating Analyzers

If you support Oracle EBS R12 then you are familiar with the Oracle Analyzers. They are essentially reports that were designed by Oracle Support to assist with diagnosing issues by providing detailed analysis and even some potential solutions, like applying a relevant generic data fix or suggesting a patch. These analyzers can also speed up your response time when creating an SR by providing the outputs for the relevant analyzers in a product family when you initiate the SR.

The issue with the Analyzers is that there are a lot of them, and maintaining them can become difficult. This is because Analyzers are basically scripts that can be ran manually by your DBA or can be setup to run as a concurrent program (not all Analyzers allow for this). What this means is that it's time consuming to install analyzers and configure them to be ran as concurrent programs and then keeping them up to date, as Oracle releases new versions of the packages behind said Analyzers rather often.

Here is where the Bundle Analyzer tool comes into play. It makes it easy to install all the available Analyzers from a menu that can be easily navigated and utilized by a System Administrator or DBA. You can also quickly load and register analyzers as concurrent programs and also have the ability to uninstall them. Basically, the tool provides a simple interface that makes it really easy to perform these tasks.

You also don't need to worry about data integrity, per Oracle, "Application data is not altered in any way when the Analyzer Bundle Menu is installed or when any Support Analyzer is run."

What this allows you to do, as a support team, is quickly spinning up the analyzers you want to use and update them on a regular basis, maybe when you do your releases, or anytime you wish and as time allows. One of the features of the tool is that you can bulk load all analyzers in a given EBS product family or even all analyzers in all families, as well as individual analyzers, if you don't want to complicate matters by having unnecessary capabilities.

The installation steps are very simple for any DBA or System Administrator, and all the steps are outlined in the below note provided by Oracle:

E-Business Suite Support Analyzer Bundle Menu Tool (Doc ID 1939637.1)

Now, while the Bundle tool greatly simplifies this effort of obtaining analyzers and updating them, there’s still manual work involved, and many of us have asked whether there's some way to automate this further.

In response, Oracle has now released a new feature allowing concurrent programs to be scheduled to address updating analyzers using the bundle tool. This can allow you to automate updating your existing analyzers on a regular basis without human intervention.

All the details in regards to this valuable enhancement to the Analyzer Bundle tool can be seen in the below note provided by Oracle. The note contains all the details around the two concurrent programs involved in the Auto Update feature and how it works.

E-Business Suite Support Analyzer Bundle AutoUpdate Concurrent Program (Doc ID 2377353.1)

This is an extremely powerful tool that can truly enhance your capabilities to support your customers proactively and I urge everyone to explore it.

Regards,

Julio