Software delivery simulation vs enterprise architecture
November 27, 2021
“We shape our buildings, thereafter they shape us.”
— Sir Winston Churchill.
In the current reality driven by technology and tight interconnections between different industries, business success hinges on collaboration, discipline, and flexibility. Of these, flexibility is arguably the essential quality to have in today’s competitive landscape. Businesses can welcome and adapt to change or try to be stubborn and eventually be thrown out of their industries.
IT concepts and approaches such as enterprise architecture, software delivery simulation, and agile development can help organizations define a solid strategy to navigate the turbulent business and tech waters. However, businesses need to clearly understand how these concepts are meant to be incorporated into their workflows. Otherwise, even the most cutting-edge tricks won’t be able to help them.
Our focus today is on enterprise architecture and software delivery simulation. Below, we will explain what they entail, what issues they are supposed to solve, and how they can be organically integrated into organizations to help achieve results!
What is enterprise architecture?
“We can simulate performances of airplanes in 3D, why can’t we do it with enterprises? This is where we should be heading – a stage where we can actually simulate how certain changes or decisions will affect the enterprise."
—John Zachman, Father of Enterprise Architecture (EA)
Although many definitions of enterprise architecture (EA) exist, not all business and IT leaders exactly understand what it is and how it can bring value to their organizations. Part of the reason for this is the obscure wording often used to describe EA. Consider this definition from Gartner as an example:
Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve targeted business outcomes that capitalize on relevant business disruptions.
Although certainly not incorrect, this definition doesn’t list the specific uses and goals of enterprise architecture. Besides, the wording used here can be confusing even for those who know exactly what EA is.
Fortunately, we can find more concrete formulations of enterprise architecture online and in literature. If we were to summarize these formulations, we would get something like this:
Enterprise architecture is a discipline aimed at helping enterprises define and organize their IT infrastructures in order to achieve their long-term business goals. Overall, enterprise architecture is used to provide a high-level description of internal IT processes to help organizations maintain competitiveness, growth, and customer satisfaction.
According to ThousandEyes, enterprise architecture operates in the following four domains:
- Business architecture – formulates the overall business strategy, governing standards, and policies of an enterprise.
- Data architecture – formulates the data assets (including data itself and data management systems) used to support an organization’s business activities.
- Application systems architecture – formulates how individual systems should be deployed and how they should interact.
- Technology architecture – formulates the hardware, software, and network infrastructures that should support data architecture and application systems architecture.
Overall, enterprise architecture can help businesses clarify their operations and provide insight and accounting of their IT tools. It can also improve communication through standard reference architectures.
What is software delivery simulation?
Software delivery simulation is a more specific and targeted process. Whereas enterprise architecture is concerned with the more global aspects of business operation, software delivery simulation seeks to help organizations plan and outline the process of software delivery before its execution.
With software delivery simulation, businesses can:
- Reduce costs and time to implementation.
- Assess and test possible scenarios without disrupting operations.
- Test many solutions and ideas in a short timeframe.
- Quickly spot bottlenecks and weaknesses in proposed systems.
- Determine how the suggested changes will impact the real-world system.
Today, simulation is arguably more useful than ever because of the perpetually changing landscape of software development/delivery. The rigid development approaches of yesterday no longer cut it, with agile approaches being predominant in the industry. Due to technological advancements and globalization, businesses must be ready at all times to adapt to their changing environments to stay relevant on the market.
Software delivery simulations can take on different forms – they can be used to represent simple, static processes, and they can also be fitted to complex systems with a multitude of known and unknown variables that change with time. With enough resources and knowledge of the target system, a simulation could potentially be used in pretty much any situation (given that there aren’t better solutions to a given problem).
How does software delivery simulation compare with enterprise architecture?
While some clear distinctions between software delivery simulation and enterprise architecture exist, an overlap is evident between their goals and functions:
- Software delivery simulation and enterprise architecture both share a relatively holistic approach to business activities. The changes and solutions they propose aren’t restricted to IT and software development and span other areas of business operations, such as supply, product, and customer chains.
- Enterprise architecture and software delivery simulation have the same high-level benefits. They can help businesses obtain a clear view of their operations today and how they can be maintained and improved tomorrow.
With that being said, if we look at specific details, we will be able to spot stark differences between the two approaches:
- Enterprise architecture is focused on documenting business processes. As with other forms of documentation and specification, these artifacts become (at best) out-of-date right after publishing. EA fundamentally aims to capture a general and static perspective of the enterprise, even though the nature of modern enterprises is centered around nuance, change, and adaptation.
- As a more targeted approach, software delivery simulation focuses on helping software delivery teams construct products that can continuously meet the needs of their users. Thanks to its innate flexibility, software delivery simulation can better align with the nuances of the real process, and it is excellently adaptable to dynamic systems.
Capturing how systems interact with their environments, simulation is inherently well-suited to changing environments. In contrast, models, diagrams, and documentation – the underlying enterprise architecture components – are inherently static.
Considering how volatile modern sociotechnical systems can be, bringing the dimension of time into the equation is a game-changer. Combined with lean and agile principles, this can allow enterprises to deliver value not only right now but also to continue delivering value months and years into the future.
Enterprise architecture quality of models and software delivery simulation quality models
The ISO/IEC 25010 standard defines quality as:
“the degree to which a product or system can be used by specific users to meet their needs to achieve specific goals with effectiveness, efficiency, freedom from risk and satisfaction in specific contexts of use.” (Section 4.1)
The product quality model defined in ISO/IEC 25010 encompasses eight quality characteristics as illustrated in Figure 1 and suggests a basis for the flexibility inherent in agile organizations.
The EA model’s quality must be evaluated from its original purpose and the concerns of its stakeholders. This suite of tool components enables EA practitioners to assess and improve the quality of corporate EA models. The goal is an exemplary EA Quality Model (QM) that can be incorporated with a Software Delivery Simulation (SDSim) QM.
The ISO/IEC standard defined five characteristics to assess a system’s quality within the context of software engineering (software delivery simulation): effectiveness, efficiency, satisfaction, freedom from risk, and context coverage. Complex systems based upon models containing significant software engineering elements can be understood more easily when using the ISO standard as a general conceptual framework for evaluating quality. The ISO approach to evaluating the quality of models distinguishes between the (Hacks, et al., 2019):
- internal properties of a product (contributing to the internal quality);
- external properties of a product (contributing to the external quality); and
- quality in use properties (properties that influence the quality and are measured when the product is in use within specific contexts).
The ISO standard is a fundamental foundation for defining the quality of software engineering models, whether the models are within an EA or an SDSim. This association of quality characteristics provides a capability to measure quantitative and qualitative properties across both disciplines. Within both disciplines, a foundational dimension of quality is information architecture. Information architects are pre-occupied with EA models, while at the same time intimately indoctrinated with the information architecture of simulation models for software delivery.
The ISO standard underscores the pragmatic rationale for any quality model, constructing a practical tool that steers design processes, in terms of requirements, and evaluation processes, in terms of quality evaluation. Let’s look at an example where EA intersects with SDSims. The EA would contain an information architecture model for the corporate websites of the enterprise. An SDSim could be developed to simulate a canary deployment of the new website version. Each would rely on the underlying QM for the website. Figure 2 illustrates the architectural components and quality model roles (actors) for the website.
A sample quality profile illustrated in Figure 3 could occur within both the EA and the SDSim. The difference between the two could be compared to test the EA for flexibility in the instance of an SDSim.
The radar diagram is an example of a quality evaluation. Note from Figure 2 that a 1-to-1 relationship between characteristics and actors furnishes an organizational mapping outcome. This is exceptionally useful when maintenance on the EA is necessary while designing and delivering the SDSim for the new enterprise website. The enterprise now has a means for evaluating the SDSim’s quality impact on the EA roles. A symbiotic relationship between the two domains exists, based upon the QMs.
Despite the outlined distinctions, enterprise architecture and software delivery simulation can both be handy tools when used correctly. In fact, in isolation from each other, EA and simulation may struggle to achieve any results.
Pretty diagrams outlining the inner workings of an organization won’t by themselves encourage change, flexibility, and propel businesses to success. At the same time, without a clearly defined IT infrastructure, simulation projects may never see good results either.
Organizations need to understand what influences their financial performance and what they can do to make influential optimizations. Enterprise architecture can help us know where we are today, what the future holds for us, and how we can achieve desired outcomes.
Understanding the realities of now is a small step in the grand scheme of things, but assigning definitions and specifications to business processes can add much-needed clarity to an enterprise’s operations. And once that’s done, software delivery simulation can help organizations leverage the solid foundations achieved with EA to drive their sociotechnical systems towards world-class performance.
Of course, this relationship between the two disciplines now begs the question, “How can agile development be integrated with both EA and SDSim”? An astute graduate learner provided significant insights into the potential relationship between EA and agile development that is worth a read in his thesis Applying Agile in Enterprise Architecture (Hensema, 2015).
Hensema, M. A. (2015). Applying agile in enterprise architecture. (Master’s thesis, University of Twente).
ISO. (2011). ISO/IEC 25010: 2011. Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models. Geneva.
Polillo, R. (2011, June). Quality models for web [2.0] sites: A methodological approach and a proposal. In International Conference on Web Engineering (pp. 251-265). Springer.
Hacks, S., Steffens, A., Hansen, P., & Rajashekar, N. (2019). A continuous delivery pipeline for EA model evolution. In I. Reinhartz-Berger, J. Zdravkovic, J Gulden, & R. Schmidt (Eds.), Enterprise, Business-Process and Information Systems Modeling: Proceedings of the 20th International Conference, BPMDS 2019, 24th International Conference, EMMSAD 2019, Rome, Italy, June 3–4, 2019. Springer. (pp. 141-155). Springer.