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