Learning Objectives
By the end of this section, you will be able to:
- Identify software engineering process patterns
- Describe the progression from software models to software implementation
The process of managing, designing, and describing the solution engineering in relation to specific business problems is called solution architecture management. A solutions architect manager is responsible for building teams, establishing relationships, setting strategy, and measuring and delivering results for any problem or opportunity the enterprise may face.
Industry Spotlight
Solution Architecture Management
Solution architecture management is important in every industry today. It plays an especially crucial role in the health-care industry. Solution architecture is used to maintain electronic health records and ensure patient data privacy and security. As health-care systems become more complex and data becomes more sensitive, solution architecture can be used to engineer secure, scalable, and efficient systems. These frameworks allow providers to access reliable information while maintaining compliance with data regulations.
Software Engineering Process Patterns
As we learned in Chapter 9 Software Engineering, the software process can be defined as a collection of patterns that define a set of activities, actions, and tasks required to develop computer software. Software engineering is a detailed study of engineering to design, develop, and maintain software. Software engineering process patterns establish collaborative communication between customers and software engineers to guarantee the successful completion of task patterns within the project requirements and the project scope.
As you may recall, various processes and related process patterns were discussed in Chapter 9 Software Engineering to explain how software solutions may be developed by refining an architecture model into a fully coded ready-to-deploy solution.
Technology in Everyday Life
Architecture Management in Real Life
Solution architecture management may not directly impact individuals in their everyday lives, but it indirectly influences their experiences through the development and management of various technological solutions. It ensures that systems like banking apps, online shopping platforms, and smart home devices function efficiently by managing how the different components of technology work together. When well-implemented, it improves the reliability and performance of these tools, making daily tasks more seamless.
Link to Learning
To learn more about enterprise architecture and how it is used in modern business and tech, explore the websites of industry publications like CIO Magazine for current insights and trends in technology management.
From Software Models to Software Implementation
Recall that a subsystem is a set of collaborating components that perform a given task included in software systems; it is considered a separate entity within a software architecture. A component is an encapsulated part of a software system, which has an interface and serves as a building block for the structure of a subsystem. Subsystems interact with other subsystems and components to perform their designated tasks. At a programming language level, components may be represented as modules, classes, objects, or as a set of related functions.
When designing architectures for software systems, software designers typically start with a requirements model (either explicit or implied) that presents an abstract representation of the system. The requirements model is a model that describes the problem set, establishes the context, and identifies the system of forces that hold sway, such as design quality attributes. The method of hiding background details (i.e., unnecessary implementation) about the data so that users only see the required information is called abstract representation.
In a traditional architecture design approach that does not leverage patterns, software designers gather the “big picture” from the requirements model and proceed with defining external entities such as other systems, devices, and people. The software system interacts with the external entities and defines the nature of the interaction. Software designers then need to identify a set of architectural archetypes and specify the structure of the system by defining and refining software components that implement each archetype. An archetype is an abstraction (similar to a class) that represents one element of system behavior.
Think It Through
Architecture and Software Engineering
Architecture activities and software engineering activities collaborate throughout the software development process. The architecture provides the blueprint for software engineers to follow, while software engineering activities provide feedback that helps architectural decisions.
Given the fact that architecture is maintained at various levels of scope within the enterprise, how do architecture activities integrate with software engineering activities?
Figure 10.46 illustrates how enterprise architecture management activities typically integrate with the solution development life cycle within enterprises. The integration of enterprise architecture management activities with the solution development life cycle ensures that solutions are developed in alignment with the organization’s strategic objectives, architectural principles, and governance requirements. It helps optimize resource allocation, streamline development efforts, enhance interoperability, and improve the overall effectiveness of technology solutions within the enterprise.
Architectural and Design Patterns
Design patterns are a representation of the previous test solutions to a specific problem, which is useful for solving future problems. When software designers think about applying patterns or start thinking in patterns, they first try to relate patterns to the requirements model, which communicates the big picture and the context in which the software to be built resides. After that, they extract the patterns that are present at that level of abstraction and begin their design with big-picture patterns that set a context or skeleton for further design work. They then work inward from the context, looking for patterns at lower levels of specialization that contribute to the design solution. The same steps of applying patterns are repeated until the complete design is fleshed out, and the design is refined by adapting each pattern to the specifics of the software being built. Per the approach, the various patterns mentioned earlier are applied to the big picture with their level of abstraction in mind.
Remember that an architectural style is a set of characteristics that make a software system notable or identifiable; it is also a transformation that is imposed on the design of the entire software system. In any software system, there is a set of architectural constraints that restrict the roles/features of architectural elements. An architectural style corresponds to coordinated roles and allows relationships among the elements within any architecture that conforms to that style. An architectural pattern expresses a fundamental structural organization schema for the software system by predefining the subsystems, predefining the subsystems’ responsibilities, creating rules and guidelines for organizing the subsystems, and building relationships between subsystems. Finally, refining the subsystems or components of the software system, or the relationships between them, is the rule of a design pattern. This provides a scheme that describes a commonly recurring structure of communicating components and solves a general design problem within the particular context of the software system.
When delving into the architectural design of a software system, it typically becomes clear that the system cannot be designed outright by just applying patterns. Thinking in patterns does help relate patterns to a technology environment requirement model and typically reveals that software solutions should leverage characteristics from several architectural styles (e.g., cloud, P2P, and microservices). It may also help identify the need to leverage the EAM, BPM, and Intelligent Autonomous Agents architectural patterns as part of a software solution.
Concepts In Practice
Enterprise Architecture and Land Development
It is easy to think about a land development project as being focused on developing a number of home communities populated with custom homes. The land development company can be considered at the enterprise level. Each individual home community is developed by business units within the enterprise, and individual homes within each home community are created as individual projects. This can be compared to what is happening as enterprise architecture is applied to manage enterprise, portfolio, and project-level architectures. At the project level, managing software projects becomes the concern of the software engineer, but it is clear that enterprise architecture is required to ensure that the individual projects are implemented to follow the guidelines established at a higher level.
Enterprise Technical Architecture Frameworks
While the architectural design approach leads the way to pattern-based design, patterns themselves may not always be sufficient to develop a complete design. In some cases, it may be necessary to provide a framework. Remember that a framework is an implementation-specific skeletal subsystem for design work. Mini-architecture provides the generic structure and behavior for a family of software abstractions. Memes (i.e., metaphors) specify the subsystems’ collaboration within a given domain. You can reuse the mini-architectures along with a meme to create the framework, which is not an architectural pattern but rather a skeleton with a collection of “plug points” that enable the framework to be adapted to a specific problem domain. The plug points—also called hooks and slots—enable you to integrate problem-specific classes or functionality within the skeleton. Therefore, a framework defines the architecture of a family of subsystems, provides the basic building blocks to create them, and defines where adaptations for specific functionality should be made. In general, patterns can be used to describe the framework as information about the system and the frameworks are software that defines a generic design.
Software Stacks
A software stack is a collection of independent components or subsystems such as operating systems, protocols, databases, architectural layers, and function calls that work together to support the execution of an application. As architectural models are being transitioned into implementation architectures, it is necessary to identify specific products that may be used as part of the implementation. This is where the selection of product/software stacks takes place. For example, a choice may be to select among IBM, Oracle, or Microsoft product stacks such as Dynamic 365 (or a combination) to implement a particular architecture.
Figure 10.47 is an example of a simple software stack for a website implementation. The stack consists of a user interface, application layer, application infrastructure, and tech infrastructure.
Once a software stack is selected, various products can be added via callouts on the corresponding implementation architecture blueprint.
Global Issues in Technology
Security of Architecture Management around the Globe
Global issues in technology can have significant implications for solution architecture management worldwide. Solution architecture management needs to address data protection regulations, ensure secure handling of sensitive data, and implement robust security measures to safeguard against cyber threats. Complying with the European Union’s GDPR requires organizations to implement strict data privacy controls. This, in turn, influences the design of global IT solutions as they must account for local and regional regulations.
Implementation Patterns and Idioms
As we discussed before, design patterns address general structural principles; in contrast, idioms represent low-level patterns that describe how to solve implementation-specific problems in a programming language, such as managing memory in C++ or Java.
As architectural models get transitioned into implementation architectures, it becomes necessary to specify how architectural and design patterns are realized practically within the solution. This mapping actually starts at a high level with the architectural styles themselves. For example, a BPM architectural style may be realized via the selection of an enterprise REST Services and with a corresponding product such as MuleSoft. This subsequently dictates the use of specific implementation patterns and idioms specific to the MuleSoft product stack.