- •
What are the patterns for enabling Interaction goals with existing enterprise systems?
- •
What are the logical patterns enabling enterprise integration?
- •
How are underlying enterprise systems and tools enlisted within these patterns?
As emphasized previously, since the organization progresses towards more comprehensive or customer circumstance-based services, it becomes necessary to support many new types of Requests. From the business perspective, the underlying enterprise interoperability problem is typically stated as a requirement to produce an improved business result from services implemented in software tools. These include communication endpoints by which the systems can be considered to be components that will interact with each other and thereby form a new, integrated service capable of performing new functions. In turn, each system that contributes information or functionality is often required to expose new services. Thus, the trend is toward exposing more-and-more functionality from existing applications and using interoperability to compose these functions in different and new ways. (Figure 1)
Figure 1. Taxonomy of Enterprise Architecture Patterns
Related work in Software Product Line 2008 is relevant as the goal here is also to create a base of reusable knowledge. According to this Software Engineering Institute site:
A Software Product Line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. Product line adoption involves moving from some form of developing software-intensive systems with a single-system mentality to developing them as a software product line. A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. The adoption objective is to:
- •
Have a core asset base, supportive processes, and organizational structures
- •
Develop products from that asset base in a way that achieves business goals
- •
Institute mechanisms to improve and extend the software product line adoption effort as long as it makes sense.
Here we also show how pattern applications can contribute to the SPL methods by describing the software architecture in a standard way that highlights the:
- •
Business context
- •
Externally visible properties of components and how they contribute to the business context
- •
Software components and structural and dynamic relationships among them
- •
Role of integration and deployment methods
Knowledge EA Governance: To briefly review, an Enterprise Knowledge Infrastructure (EKI) is for improved service delivery and related information about the communities and stakeholders. Here we show how to use architecture patterns and pattern applications to form the knowledge base with which new service options can be implemented for increased enterprise systems and business adaptability (as discussed in the previous chapter). The EA team can use this EKI to increase its maturity and performance as follows:
- •
Identify the market drivers for new services and their impact to the functional and non-functional architecture attributes and their future states. For example, several services might require more flexible ways of managing customer communities as a way of delivering custom services and this identifies significant re-use potential.
- •
Maintain a catalog of pattern applications and reference implementations as practice knowledge. Identify common functional and non-functional requirements that in turn can be reused to develop new services more rapidly.
- •
Challenge the new requirements and underlying patterns with use cases and proof of concept projects that will make them viable for greater re-use. For example, several projects might be developing ‘facades’ and ‘mediators’ as a way to progress to architectures that provide services that are composable. Make these robust.
- •
Identify redundant investments and opportunities for reuse through architecture standardization across the corporation, based on frequency of occurrence.
Motivated by these goals, here we will cover the taxonomy of EA patterns and applications illustrated in Figure 1. These applications and the underlying patterns (Adams et al, Alexander 1979, Fowler 2003, Fowler 2005, Gartner 2005, Gamma et al 1995) illustrate how different organizations are modifying existing enterprise systems to deliver new services. The top-to-bottom summary is as follows:
- •
Conceptual patterns: These patterns provide ways to apply enterprise systems to enable new Interactions and performance. Examples include aligning Customer-Provider RED Interactions to SL goals, Triage or virtualization, Shared resource OLs to enable multi-use. In addition they collect time-variant information that can lead to monitoring and mining of organizational knowledge. Overall these patterns treat the underlying IT infrastructure from a user perspective and make it easier to deliver new services by addressing the users’ interaction patterns and the domain details. Examples of underlying knowledge issues addressed include deployment of the Interaction ontology using related patterns and user perspectives.
- •
Logical patterns: The logical patterns identify the component services needed to implement security and compliance, use of application frameworks for display-rich and multi-tier applications, data warehousing and mediation.
- •
Operational patterns: The operational patterns are processes for installed architecture monitoring and improvement. Some of these are on ITIL and include management for reliability and high availability, and monitoring.
The EA template given in the previous Chapter 3 is used here for documentation but, in the interest of space, only the aspects that lead to useful illustrations are expanded.