Architecture Patterns

Mark Skilton
Dec 15, 2004
18 min read

1 Patterns

The definition of a pattern is a “a general reusable solution to a commonly occurring problem within a given context”. Patterns in the context of software architecture refer to the commonly found issues in developing systems and interfaces that can be resolved by using proven system design models and technology. These specific configurations of the systems and technology can be catalogued and defined as a pattern. Conversely, patterns can therefore also be seen and used to define what it is in the business and systems architecture and IT estate that describes the key services and solutions that business and IT programmes and projects should try to implement. In this way standards and the aim of reuse can be accommodated and promoted during product and development life cycles. Patterns can be repeated common solutions to simple problems such as a gateway interface for many systems to access or it can also be termed as the Strategic competency or capabilities that define what the business systems architecture must do well at in order to compete. In that sense, patterns taken to their full use means getting to the heart of what defines the reference architecture of a business.

The aim is to take advantage of the savings in design time and cost from using these patterns. Through appropriate levels of pattern combinations; maintainability, adaptability and scalability can be focused on, for example in container and adapter design for legacy systems management or syndication of new content delivery services channels.

The aim is not to reduce the competitiveness of the corporation through simplifying and lowering the barriers to copying the design solution but to maximise the deployment of the capabilities through a combination of ownership of effective IT infrastructure capabilities and efficient systems design. This point illustrates the trade-off between patterns and strategies.{see Appx 1).

There are many types of patterns that can be abstracted out with their own classification systems. Patterns can be found in any area of the business systems definition, design, development and deployment and support cycle.

Business patterns – relate to how business wants to offer products and services. Business Patterns include User to Business (C2B) – Self Service, User to user (C2C) collaboration; User to data (C2D) – information aggregation and Business to business (B2B) integration – extended enterprise. These represent to types of customer experience and products and service capabilities and can be described by business process and service solutions which can embody industry standards models as found in CPFR, SCOR , SID as well protocols found in B2B, WML, SOAP, XML, HTML. Analysis Patterns relate to specific business process capabilities and services in an organisational context.

Figure 1 Pattern taxonomies

A reference Architecture is composed of multiple architectural patterns. An Architecture pattern can leverage multiple design and analysis patterns.

Service and Integration Tier Patterns refer to the types of infrastructure and domains of solutions that can be deployed to meet the Business Pattern and customer requirements. These include: Portals, B2B, B2C and Mobile channel collaborative tools; Middleware Infrastructure MOMs, EAI , and ETL; Data warehousing, Business Intelligence BI and Enterprise Content Management ECM; COTs and Enterprise Information System such as ERP, CRM, ERM and SCM.

Runtime patterns are the actual physical deployment platforms and associated performance characteristics that are implemented to meet the above solution needs.

2 Tiers

In defining patterns it is useful to define a schema or framework to categorise the types of patterns at the point they are used in the logical business systems architecture tiers[1][2].

Figure 2 Tiers

[1] Thttps://www.livemeeting.com/cc/capgemini/join?id=G5P2N9&role=present&pw=d44%40StHhis is based on the J2EE architecture tiers but also has principles that can to applied to non-J2EE architectures

[2] The POSA1 patterns uses a 4 level convention: Application, Component Services Layer, Middleware and OS Abstraction Layer. This again is similar to the J2EE abstraction layers and illustrate the same principle layers.

3 Pattern to Tier Catalogue

Taking a wider view of the Pattern strategy described in the last sections requires a more complete definition of the business and systems architecture. Namely we need to link the Business Strategies and Analysis Patterns as well as the underlying Systems and software architecture patterns.

The business strategies and Business capabilities can be described in terms of Analysis patterns. The Industry standards, the Business processes, use cases can be used to define the critical Business capabilities. The Strategies for COTS, EIS and Client Interactions (Customer Experience, B2B, Employee portals etc) can also be related

Figure 3 Pattern Alignment

to specific Client and Resource Tiers and defined as patterns e.g. the COTS pattern for Customer Order management will involve a CRM Package.

The Design and Architectural Patterns (in Figure 1) can be categorised into the Presentation, Business and Integration Tiers. These must describe and align with the overall capabilities.

4 Defining the patterns[3]

From the previous section we have describe a framework for cataloguing Patterns as shown in the following diagram.

Figure 4 Pattern catalogue

Getting right to the point of patterns requires an understand and definition of the differences between the Design View of the Architecture (also called the Logical Architecture) and the Deployment Architecture (also called the Physical Architecture).

The development of Architecture strategy and the use of patterns is explored in Appendix 2.

Figure 5 Architecture Strategy as patterns

[3] The enterprise architecture and Enterprise Architecture Blueprint EAB methodology could be supported by various model abstractions at the tier model level.

5 Models to describe Pattern Catalogues

A standard industry model such as UML can be used to define the characteristics of the pattern in the systems architecture. Patterns can be defined in this model taxonomy by packaging a number of elements in UML that represent the pattern at a level in the tiers:

use cases , business and system level
Classes
Objects
Sequence diagrams and objects and flows
Activity Diagrams and actions, objects and flows
Component Diagrams and components, interfaces and objects
Deployment Diagrams and components, nodes, interfaces, objects
Collaboration Diagrams and objects
State Diagrams and objects, flows

For example in the Telecoms Industry[4], the TMF SID Telecoms Standard model approach is fully compliant with UML. All SID specifications are built upon a common NGOSS MetaModel, which is a defined extension to the UML MetaModel. Full use is made of UML compliant Use Cases, Class Diagrams and Transition Diagrams to express SID models. Rational Rose and XDE is the tool used to store and present SID models. In addition, rational Rose or XDE HTML output can also be used for viewing (giving visual verification capabilities of requirements with users). (Rational XDE also has the ability to select UML packages as Patterns and store these as a Pattern Library). SID is also part of a larger NGOSS framework which corresponds to the ISO ODP reference model. DMTF’s CIM pre-dates SID in its development. CIM’s meta-model is defined in the CIM Specification, and is object-oriented in nature. It is based on UML. The CIM Specification defines a Managed Object Format (MOF) textual representation of classes, objects, their properties and methods, and associations. This was designed to be both human and machine readable. UML diagrams rendered using Visio, are provided for presentation format. Open-source tools are available to convert MOF into Rational Rose/XDE, and work is ongoing to render the model directly in XML Schema. Instance diagrams and use cases are part of the model development process. CIM also uses Web protocols and encoding standards (HTPP, SOAP, XML, WSDL and grid technologies) for the interoperable exchange of management information.

Pattern definition using the UML standard provides[5]’[6]:

Strategic View of the Pattern
Static View of the pattern
Using Class Diagrams to represent the structure of the pattern solution and the structure of the implementation strategies (Deployment architecture)
Dynamic View of the pattern
Using Sequence Diagrams in particular to define the interactions
Object Stereotypes
Using Stereotype to define the types of objects and roles in the class and sequence diagrams
Components
Using the Component and deployment diagrams to define logical and physical pattern deployment domains

[4] Reference from TMF and DMTF joint statement June 2003

[5] 4+1 framework defines Structural as Logical View; Behavioural as Process view; Implementation as Development View and Environment as Physical view. This method described is consistent with this.

[6] The relation to Service Oriented Architectures (SOA) could be described by all the Tiers in the Tier Model. Basic Layer services are at the Integration and Resources/database tiers. Process Layer describing services and orchestration can be defined in the Business and Integration tiers. The presentation tier and overarching Analysis patterns can define the exposure of the services to clients, resources and web services. SOA could be described as a series of exposures and orchestrations at different granularities with loose coupling to align and enable strategies.

6 Criteria for defining a pattern

Implementation strategy (Deployment Architecture) may be different in technology but the underlying principle of the overall solution architecture (Framework Architecture) pattern is preserved.
Rule of Three. If a solution can be identified within at least three systems it is defined as a pattern
The pattern supports a business capability/ strategy objective
The pattern supports a higher level of abstraction (tier)
The pattern provides an extensibility point for inventing new ways to deploy the pattern architecture and to produce new strategies
The pattern supports the communication of the higher level business capability/ strategy to aid better naming and definition of the lower tier supporting design characteristics.

7 ReFactoring

This is a series of steps involved in moving from a less optimal solution to a preferred one. Bad practices in software and architecture design can lead to inefficient designs. The use of Patterns refactoring is an approach that can be employed to optimise the design for better modularity, reusability and maintainability of the application or infrastructure for future use.

8 Examples of bad architecture practice

Multiple database connections – database connections not shared resulting in complex tracking and modification to all connections if a change is required
Embedding the data access rules with control in the presentation tier. Control code in multiple views resulting in changes having to be made in multiple places. This introduces tight coupling between the presentation and application tiers restricting modularity and reusability.
Placing the Presentation and application and business logic into one tier requiring all the elements to be modified rather than decoupling the elements
Exposing the presentation tier data structures to business tier and domain objects. This increased to coupling between presentation and the underlying business services increasing complexity.
Mapping the object model directly onto the Entity Model and relational models resulting is many fine grained objects with impact on system performance, scalability and complexity. The approach misses the opportunity to introduce composite entities and optimised message sessions
Mapping every system use case to a session resulting in many fine grained messages with impact on system performance and scalability. The approach misses the opportunity to cache messages and use of a façade to aggregate a batch of related sessions into a single session.
Embedding interface services in the clients resulting in any change requiring all the clients to be modified
Duplicating the source data structure in the middleware layer increasing inefficient data access and updates.
Ineffective handling and direction of exception messages from the integration tiers to the client resulting in lack of resolution. The approach does not decouple the exception handling business logic into the business tier away from the client tier.
Inefficient get list calls on the remote database resulting in many multiple calls to the database with subsequent overhead costs and performance. The approach misses use of other methods to return query lists.
Aggregating the composite data and business information in the Client tier resulting in increased messaging and overhead on getting the information by the client with additional significant coupling resulting in any change having to be applied to all clients that conduct this operation. The approach misses decoupling of Client tier from Presentation and business tiers.
Inefficient synchronous messaging and statefully manage when this could be decoupled and implemented as a asynchronous processing service and use of a method to facilitate long-lived transactions (e.g. Java Message Services (JMS) API)
Inefficient use of stateless sessions to manage a conversational session resulting in increased overhead of rebuilding the stateless session with every conversational event.

9 Examples of good architecture practice using Pattern Refactoring

Presentation Tier
identifying ways to extend the façade to support multiple uses
identifying ways to keep the presentation tier independent from the underlying business and integration tiers
Business Tier
Identifying ways to keep business logic separate from the Presentation, Integration and Resource Tiers
Identification of wrapping entities for a session to encapsulate the logic required for a service.
Identification of ways to locate automated business logic where appropriate
Integration Tier
Identifying ways to manage common information and transformations separate from the source and target systems
Identifying ways to split out the architecture into presentation, business, integration and resource tiers more effectively
Resource Tier
Identifying ways to keep the COTS and other EIS systems hidden from direct access of the Client tier to control/manage access
Identify ways to share database connections – use of common adapters and gateways.

10 Activities for Pattern refactoring

Most businesses are in the state of multiple programmes, legacy applications as well as future strategic initiatives. Refactoring must work on the current and future portfolios. Activities are:

Pattern Mining in the implemented solutions
Pattern cataloguing
Pattern catalogue referencing
Pattern Mining in the new design solutions
Redesign of the solution during development
Redevelopment(refactoring) of the implemented solution to support Pattern Catalogue

Figure 6 Pattern Refactoring Process

11 Summary - Characteristics of a pattern

A Common capability to many systems and platforms
Is strategically significant
Is architecturally significant
Supports reuse
Maintainability
Scalability
Modularity
Flexibility
A pattern is not a reference Architecture – but an element of the Architecture that can be reused and is part of the reference architecture
Easy to understand and visualise the capabilities
Easy to keep pattern up-to-date
Pattern catalogue is part of the IDE and easily accessible but under control by programme governance
The IDE must include Business Analysis and the Business. Both these parties must understand and support the capabilities. The specific context of the capabilities and the underlying broad principles of the pattern capabilities. (The patterns should be flexible to move with business strategic direction and not act as a barrier.)
Aids communication of capabilities
Evolves with time
Has a Logical and Deployment Architecture view defined in Component and Deployment Models
Has an underlying Class and sequence model that defines its static and dynamic characteristics which is applicable to both Logical and Deployment Architecture view – BUT may have trade-off decisions that limit its extent of deployment – but in principle supports the pattern capability (which is aligned to a strategic imperative.)

Mark Skilton

Sunday, 24 July 2016

Appendix 1 Pattern Catalogue

Specific Patterns that can be categorised by pattern type and Tier are as follows[7].

Table 1 Pattern Catalogue – Tier Ontology reference List

[7] This is not an exclusive list and can be added to

[8] This can be referenced in many pattern books and Libraries where indicated. See Bibliography as end of this article

[9] GoF Gang of Four. See Book reference: Design Patterns – Elements of Reusable Object-Oriented Software: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

[10] POSA Pattern-Oriented Software Architecture – Douglas C.Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann. Wilet & Sons 2000. This book is the second volume in the POSA Series. POSA1 was published in 1996 and the 2000 book is referred to as POSA2. POSA3 for Resource Management 2004

[11] PEAA Patterns of Enterprise Application Architecture, Martin Fowler, Addition Wesley 2004

[12] Defines concepts of common façade and object handling for message aggregation and query searching. Requires development of

[13] J2EE reference and concept of persistence also illustrated here

Pattern Catalogue - Business Pattern Ontology

General Performance of Architecture

What are the overarching best practice principles of the Business patterns:

Performance management,
Systems management,
Application Design patterns,
Technology Choices

Technical Investment

What are the Technology choices for intra and extra-enterprise architecture

Extra-enterprise:

XML as a data exchange technology,
Connector technologies,
Web Services – loose coupling,
Asynchronous messaging,
Source and Target mapping and services to link,

Intra-enterprise:

Similar to extra-prise

Customer to Business C 2 B

Self Service

Customer to Customer C 2 C

Collaboration

Customer to Data C 2 D

Content Sourcing

Content Acquisition

Content aggregation

Content Syndication

Content Deployment

Customer services

Business to Business B 2 B

Extended Enterprise services

Business to Employee B 2 E

C 2 B

Employee to business E 2 B

C 2 B

Composite Patterns

These are combinations of applications, integration and business patterns. Composite patterns can support services for specific business pattern needs.

Electronic Commerce

e-Marketplace

Portals

Application Patterns – process oriented for integration

Application Patterns – implement the functionality of the application(s) required for the Business pattern

Integration Patterns – application functionality orientation for integration

Identification and verification patterns

[if !supportLists]· [endif]Application Integration

See below for application data integration patterns

Integration Patterns – application data orientation for integration

Integration Pattern- Messaging patterns

Integration services characteristics

[if !supportLists]- [endif]Protocol adapters

[if !supportLists]- [endif]Message handlers

[if !supportLists]- [endif]Data Transformation

[if !supportLists]- [endif]Decomposition / recomposition

[if !supportLists]- [endif]Routing / navigation

[if !supportLists]- [endif]State management

[if !supportLists]- [endif]Security

Pattern Catalogue - Analysis Pattern Ontology

The evolution of two tier to three tier information systems architecture and distributed architectures has enabled the abstraction of business data (decoupling) from the application and presentation layers. Further more, data and information processing in the integration layer has enable business processes and data to be encapsulated and designed and managed as entities in their own right.

[if gte vml 1]><v:shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"> <v:stroke joinstyle="miter"></v:stroke> <v:formulas> <v:f eqn="if lineDrawn pixelLineWidth 0"></v:f> <v:f eqn="sum @0 1 0"></v:f> <v:f eqn="sum 0 0 @1"></v:f> <v:f eqn="prod @2 1 2"></v:f> <v:f eqn="prod @3 21600 pixelWidth"></v:f> <v:f eqn="prod @3 21600 pixelHeight"></v:f> <v:f eqn="sum @0 0 1"></v:f> <v:f eqn="prod @6 1 2"></v:f> <v:f eqn="prod @7 21600 pixelWidth"></v:f> <v:f eqn="sum @8 21600 0"></v:f> <v:f eqn="prod @7 21600 pixelHeight"></v:f> <v:f eqn="sum @10 21600 0"></v:f> </v:formulas> <v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"></v:path> <o:lock v:ext="edit" aspectratio="t"></o:lock> </v:shapetype><v:shape id="_x0000_s1029" type="#_x0000_t75" style='position:absolute; margin-left:0;margin-top:8.4pt;width:279pt;height:213.3pt;z-index:251661312'> <v:imagedata src="file:///C:/Users/MARKSK~1/AppData/Local/Temp/msohtmlclip1/01/clip_image001.wmz" o:title=""></v:imagedata> <w:wrap type="square" side="left"></w:wrap> </v:shape><![endif][if !vml][endif]

Figure [if supportFields]> SEQ Figure \* ARABIC <![endif]7[if supportFields]><![endif] n-tier architecture - evolution

As a result these developments businesses can establish Domain Models of strategic competencies.

Separating presentation and application logic have enable data and functions to be considered as discrete entities. Introducing an integration tier enables further distribution and management of front end and back end systems in the solution stack with Business Logic placement and Data location and transformation rules now key elements of the

This enables different Facades to be created across presentation and application tiers as well as database and integration tiers. The former types enable portal and workflow/ web service composite models; the latter focusing on integration hubs, gateways and buses for interface and data management.

Figure [if supportFields]> SEQ Figure \* ARABIC <![endif]8[if supportFields]><![endif] application architecture tier ontology - Gartner 2004[if gte vml 1]><v:shape id="_x0000_s1028" type="#_x0000_t75" style='position:absolute;margin-left:18pt;margin-top:.8pt;width:431.75pt; height:336.15pt;z-index:251660288;mso-position-horizontal-relative:text; mso-position-vertical-relative:text'> <v:imagedata src="file:///C:/Users/MARKSK~1/AppData/Local/Temp/msohtmlclip1/01/clip_image005.wmz" o:title=""></v:imagedata> <w:wrap type="square" side="left"></w:wrap> </v:shape><![endif][if !vml][endif]

Analysis Patterns from Domains

Business analysis patterns can be created to exploit these new architecture frameworks.

Domain models can create application facades to describe key business competencies.

Facades can occur in multiple groups.

[if gte vml 1]><v:shape id="_x0000_i1025" type="#_x0000_t75" style='width:333pt;height:265.9pt'> <v:imagedata src="file:///C:/Users/MARKSK~1/AppData/Local/Temp/msohtmlclip1/01/clip_image007.wmz" o:title=""></v:imagedata> </v:shape><![endif][if !vml][endif]

Figure [if supportFields]> SEQ Figure \* ARABIC <![endif]9[if supportFields]><![endif] Browser Façade

Figure [if supportFields]> SEQ Figure \* ARABIC <![endif]10[if supportFields]><![endif] Application Façade

[if gte vml 1]><v:shape id="_x0000_s1031" type="#_x0000_t75" style='position:absolute;margin-left:9pt;margin-top:.1pt;width:387pt;height:353pt; z-index:251663360'> <v:imagedata src="file:///C:/Users/MARKSK~1/AppData/Local/Temp/msohtmlclip1/01/clip_image009.wmz" o:title=""></v:imagedata> <w:wrap type="square" side="left"></w:wrap> </v:shape><![endif][if !vml][endif]

[if gte vml 1]><v:shape id="_x0000_i1026" type="#_x0000_t75" style='width:357pt;height:501.4pt'> <v:imagedata src="file:///C:/Users/MARKSK~1/AppData/Local/Temp/msohtmlclip1/01/clip_image011.wmz" o:title=""></v:imagedata> </v:shape><![endif][if !vml][endif]

Figure [if supportFields]> SEQ Figure \* ARABIC <![endif]11[if supportFields]><![endif] Separation of presentation, facade and Domain model concept

[if gte vml 1]><v:shape id="_x0000_i1027" type="#_x0000_t75" style='width:467.65pt;height:489.4pt'> <v:imagedata src="file:///C:/Users/MARKSK~1/AppData/Local/Temp/msohtmlclip1/01/clip_image013.wmz" o:title=""></v:imagedata> </v:shape><![endif][if !vml][endif]

Figure [if supportFields]> SEQ Figure \* ARABIC <![endif]12[if supportFields]><![endif] Domain to Database Interface tier

Appendix 2 – Trade-off between Pattern design and Deployment strategy

Trade-offs existing between optimising the design of a solution to conform to a technology or business process pattern and the return on value from the investment.

In order for a Company to provide its VALUE PROPOSITIONS a firm has to be able to deploy as set of CAPABILITY(ies) . Capabilities can be described as repeatable patterns of action in the use of assets to create, produce, and/or offer products and services to the market[if !supportFootnotes][1][endif]. (Wallin, 2000). These capabilities depend on the assets or resources of the firm and the ability to deploy these resources which increasingly may be outsourced and /or involve 3rd parties and multiple channels.

[if gte vml 1]><v:shape id="_x0000_s1027" type="#_x0000_t75" style='position:absolute;margin-left:0;margin-top:2.6pt;width:270pt;height:126.9pt; z-index:251655168'> <v:imagedata src="file:///C:/Users/MARKSK~1/AppData/Local/Temp/msohtmlclip1/01/clip_image015.wmz" o:title=""></v:imagedata> <w:wrap type="square" side="left"></w:wrap> </v:shape><![endif][if !vml][endif]

Figure [if supportFields]> SEQ Figure \* ARABIC <![endif]13[if supportFields]><![endif] Capability ontology

The trade-off is between building deployable patterns and meeting the business strategy needs

[if !supportLists]- [endif]patterns issues

[if !supportLists]o [endif]Extensibility and scalability of the need

[if !supportLists]- [endif]Strategic issues

[if !supportLists]o [endif]Time and uniqueness of the value proposition

Design and deployment may need to violate the pattern in order to meet timescale and new strategic needs but at the same time needs to exhibit pattern based characteristics for generic reuse and scalability. Some investments in IT have been over optimised and customised to a point where reuse has been lost and the Whole-of-life cost has increased as a result.

Figure [if supportFields]> SEQ Figure \* ARABIC <![endif]14[if supportFields]><![endif] Tradeoff between Pattern and Strategy

Appendix 3 - Pattern References

This section is a collection of recent pattern ontologies from research books and Competitors.

Notable from this is the evidence of pattern design used in defining architectures and new ontologies

The move away from B2B, B2C, C2B definitions to new taxonomies of architecture covering:
Composite patterns
Where by multiple functions are combined into a composite application. Examples of these:
Ecommerce
E-marketplaces
Portals
Treading exchange – buyers and sellers on a public site
Sell side hub, seller owns hub activity – used to sell products/services
Buy side hub , buyer owns hub – “ebay”- eAuction of a contract to get best offer price from prospective service providers.
Business patterns

Where by earlier definitions of business entities relations i.e. B2B, B2C, C2B are replaced by the services they are seeking to deliver in these exchange types:

[if !supportLists]· [endif]C2B à Self-service

[if !supportLists]· [endif]C2C à Collaboration

[if !supportLists]· [endif]User to data (C2D) à information aggregation

[if !supportLists]· [endif]B2B à Extended enterprise

[if !supportLists]o [endif]Integration patterns

[if !supportLists]· [endif]In this context are just seen as devices for connectivity and orchestration with the business patterns to offer the composite services.

[if !supportLists]o [endif]Access integration

[if !supportLists]o [endif]Application integration

[if !supportLists]o [endif]Application patterns

[if !supportLists]· [endif]These are the specific types of functionalities and services available from applications and the select of COTs and Composite services solutions to meet customer requirements. The other patterns describe what needs to be deployed.

[if !supportLists]o [endif]Runtime patterns

[if !supportLists]· [endif]These are patterns for developing the deployment architecture, backend and front end solution and the physical architecture

[if !supportLists]· [endif]This includes the performance and user experience qualities from the solution

The key element here is to see service in the wider aspect of architecture. Specifically, what is the purpose of the architecture and what is the underlying infrastructure being used for. The new category user to data C2D is a clear indicator of the emergence of content driven online services or, digital services. These represent significant shifts in the underlying IT and services.

Development of a Service oriented Architecture in this context is a wider issue of how services and architecture are developed and deployed.

Pattern solution offering are increasing being seen as a ontology in architecture. Offering a pattern design approach is critical to the solution set be offer by IT services companies.

Selection of the integration approach for intra and extra- enterprise services is an essential critical strategy.

IBM Patterns for e-Business.

A layered assets model.

http://www-106.ibm.com/developerworks/patterns/

Reference: Patterns: Broker Interactions for Intra- and Inter-enterprise

[if gte vml 1]><v:shape id="_x0000_i1028" type="#_x0000_t75" style='width:262.5pt;height:204pt'> <v:imagedata src="file:///C:/Users/MARKSK~1/AppData/Local/Temp/msohtmlclip1/01/clip_image019.png" o:title=""></v:imagedata> </v:shape><![endif][if !vml][endif]

Figure [if supportFields]> SEQ Figure \* ARABIC <![endif]15[if supportFields]><![endif] Layers e-business patterns asset model circ Nov 2004

The following extract is from the IBM web site.

Patterns for e-business are a group of reusable assets that can help speed the process of developing Web-based applications. This site breaks down these reusable assets into the following elements:

Business patterns identify the interaction between users, businesses, and data. Business patterns are used to create simple, end-to-end e-business applications.
Integration patterns connect other Business patterns together to create applications with advanced functionality. Integration patterns are used to combine Business patterns in advanced e-business applications.
Composite patterns are combinations of Business patterns and Integration patterns that have themselves become commonly used types of e-business applications. Composite patterns are advanced e-business applications.
Custom designs are similar to Composite patterns, as they combine Business patterns and Integration patterns to form an advanced, end-to-end solution. These solutions, however, have not been implemented to the extent of Composite patterns, but are instead developed to solve the e-business problems of one specific company, or perhaps several enterprises with similar problems.
Application and Runtime patterns are driven by the customer's requirements and describe the shape of applications and the supporting runtime needed to build the e-business application.
Product mappings to populate the solution. The product mappings are based on proven implementations.
Guidelines for the design, development, deployment, and management of e-business applications.

The Patterns leverage the experience of IBM architects to create solutions quickly, whether for a small local business or a large multinational enterprise. As shown in the following figure, customer requirements are quickly translated through the different levels of Patterns assets to identify a final solution design and product mapping appropriate for the application being developed.

Bibliography

Core J2EE Patterns, Best Practices and Design Strategies 2nd Edition. Deepak Alur, John Crupi, Dan Malks. Prentice Hall 2003
Design Patterns, Elements of Reusable Object-Oriented Software. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Addison Wesley 1995
Analysis Patterns, reusable Object Models. Martin Fowler. Addison Wesley 1997
Pattern-oriented Software Architecture – Volume 1 a set of Patterns, Wiley & Sons 1996
Pattern-oriented Software Architecture- Volume 2 Patterns for Concurrent and Networked Objects. Douglas C.Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann. Wiley & Sons 2000
Pattern-oriented Software Architecture – Volume 3 Patterns for Resource management. Wiley & Sons 2004
Constructing Blueprints for Enterprise IT Architects, Bernard Boar. Wiley 1999
Object Lifecycles. Modelling the world in states. Sally Shlaer, Stephen Mellor. PTR Yourdon Press. 1992
Applying UML and Patterns- an introduction to Object-Oriented Analysis and Design (OOAD) and the Unified Process. Craig Larman. Second Edition. PH PTR. 2002
Enterprise Integration Patterns- Designing, building and deploying messaging solutions. Gregor Hohpe, Bobby Woolfe. Addison Wesley. 2004
Patterns of Enterprise Application Architecture. Martin Fowler. Addison Welsey. 2003
MDA Explained- The Model Driven Architecture: Practice and Promise. Anneke Kleppe, Jos Warmer, Wim Bast. Booch Jacobson Rumbaugh series Editors. Addison Welsey 2003
Adopting the Rational Unified Process – Success with RUP. Stefan Bergstrom, Lotta Raberg. Booch Jacobson Rumbaugh series Editors. Addison Welsey 2004
Mastering Rational XDE. Wendy Boggs, Michael Boggs. Sybex 2003
Executable UML- a foundation for model-driven architecture. Stephen J. Mellor, Marc J. Balcer. Addison Wesley 2002
Executable UML –How to build Class Models. Leon Starr. PH 2002
Building Web Applications with UML second Edition. Jim Conallen. Addison Wesley 2002
Service oriented Architecture – a field guide to integrating XML and Web Services. Thomas Erl. Prentice Hall 2004
Understanding Web Services – XML, WSDL, SOAP, and UDDI. Eric Newcomer. Addison Wesley 2002
XML Web Services and the Data Revolution Coyle, Frank P.
Enterprise SOA - Service Oriented Architecture Best Practices. Dirk Krafzig, Karl Banke, Dirk Slama. Prentice Hall November 2004
MetaData solutions – using Metamodels, repositories, XML, and Enterprise Portals to generate Information on Demand. Adrienne Tannenbaum. Addison Wesley 2002
Mastering Data Warehouse Design – relational and Dimensional Techniques. Claudia imhoff, Nicholas Galemmo, Jonathan G. Geiger. Wiley 2003
Out of the box – Strategies for achieving profits today and growth tomorrow through Web Services. John Hagel III HBS Press 2002
Business Process Management the third wave. Howard Smith, Peter Fingar. Meghan-Kiffer Press 2002
Convergence of Telecommunications and Enterprise Management. Joint Position Statement on Behalf of the TeleManagement Forum (TMF) and Distributed Management task Force (DMTF). June 2003. http://www.dmtf.org/zdata/DMTF-TMF_JointPositionStatement_June2003.pdf#search='tmf%20sid'
Value Creation from e-Business models, Wendy Currie. Elsevier Butterworth Heinemann 2004