By Dr. Gopala Krishna Behara
Reference architecture provides needed architectural information that can be provided in advance to an enterprise to enable consistent architectural best practices. Enterprise Reference Architecture helps business owners to actualize their strategies, vision, objectives, and principles. Reference Architecture evaluates IT systems based on goals, principles and standards. It helps to reduce IT costs by increasing functionality, availability, scalability, etc.
A Reference Architecture provides a methodology, set of practices, template, and standards based on a set of successful solutions implemented earlier. These solutions have been generalized and structured for the depiction of both a logical and a physical architecture, based on the harvesting of a set of patterns that describe observations in several successful implementations. It helps as a reference for the various architectures that an enterprise can implement to solve various domain problems. It can be used as the starting point or the point of comparisons for various departments/business entities of an enterprise, or for the various enterprises. It provides multiple views for multiple stakeholders. Many domains have their reference architecture definitions. The industry specific key reference architecture examples are,
- BIAN service landscape for the banking industry
- ACORD Framework for the insurance industry
- AUTOSAR is a type of component-focused reference architecture for vehicle software.
- APQC provides cross-industry, or industry-specific, business process reference architectures. APQC is often used as a foundation for business process modelsor capability models.
- GSRM (a.k.a. Government Services Reference Model) provides a generic model of government services.
- Telecom Reference Architecture from TMForum, for example: Telecom Reference Architecture (https://www.bptrends.com/bpt/wp-content/publicationfiles/FOUR%2007-10-ART-Telecom-Reference%20Arch-Gopala%20et%20al.pdf)
- Government reference architectures, for example: Next Generation Reference Architecture For Connected Government (https://www.bptrends.com/bpt/wp-content/uploads/03-07-2017-ARTNext-Generation-Reference-Architecture-for-Connected-Government-Gopala.pdf)
- Oil and Gas Reference Architecture, for example: Upstream IT reference architecture (https://news.microsoft.com/download/archived/presskits/industries/manufacturing/docs/UpstreamArchitecture.pdf)
- Defense architecture frameworks such as NAF, DODAF, and MoDAF
- Reference architectures for manufacturing and supply chains such as ISA-95 and SCOR
Major artifacts of the Enterprise Reference Architecture are methodologies, standards, principles, building blocks, metadata, design patterns, etc. Reference Architecture is not same as solution architecture. It provides the framework and not ready for the implementation.
During the course of assignments/experiences with various EA consulting engagements, the author come across the following observations. Some of these indicate a lack of maturity of the enterprise Initiatives and advanced technologies. The lack of Enterprise Reference Architecture leads to the following pitfalls at different levels.
- Transformation of business structures to align with customer requirements
- BU/LOB to BU/LOB communication is not established. Geography spread of the usage of the services is not existing
- Redundancy of the Business capabilities in different applications. Reusable application services are not built
- Reference architectures exist but they are outdated. There exist multiple versions of reference architectures, which need to be updated on timely basis
- Templates, guidelines standards and reference architecture are defined by the solution architects at the project level not at the enterprise level
- Most of the enterprise Business Units/departments/agencies have developed significant amount of in-house or home-grown applications which are not flexible
- Lack of Mobile Centric approach
- Most of the applications do not have the required scalability, maintainability to sustain growth in volumes or functionality
- Applications face interoperability issues with other applications in the enterprise landscape. Integrating a new application or process requires a considerable effort on part of the other applications
- Application boundaries are not clear and functionality which is not in the initial scope of that application gets pushed onto it. This results into development of the small & multiple applications without proper boundaries
- Usage of Legacy systems, Poor Integration across various applications and Internal Systems. Most of the Integrations are developed on ad-hoc basis and Point to Point Integration
- Fragmented data across the different applications and no integrated view of the Strategic data
- Lot of Performance Issues due to the usage of the Complex Integration across various departmental systems
The collaborative efforts of enterprise to overcome some of above listed problems have resulted in induction of consulting bodies to come up with frameworks for business processes, data, applications, and technology for organization Transformations. These are the good starting point for organizations to clean up their enterprise landscape.
Importance of Enterprise Reference Architecture
In most of the cases, architects spend lot of time researching, investigating, defining and re-arguing architectural decisions. It is like reinventing the wheel as their peers in other organizations or even the same organization have already spent lot of time and effort defining their own architectural practices. This prevents the organization from learning from its own experiences and applying that knowledge for increased effectiveness.
Reference architecture provides missing architectural information that can be provided in advance to project team members to enable consistent architectural best practices.
Enterprise Reference Architecture helps an Enterprise to achieve the following at the abstract level,
- Reference architecture is more of communication channel to an enterprise
- Enterprise Reference architecture can be starting point for the Architects to accommodate their strategies, vision, objectives, principles and defining different set of architectures like business, application, cloud, and Integration architectures
- It evaluates the IT systems based on Architecture Goals, Principles, and standards It helps in reduction in the IT spending and time in terms of increasing re-use of the enterprise information, architecture building blocks and processes
- Reduction in the IT spending in terms of increasing functionality, availability and scalability etc
- Real time Integration Model, helps to reduce the latency of the data updates
- Used to define single source of Information
- Provides the clear vision on the managing of the information and security
- Define the policy around the data ownership, Product boundaries etc
- Help Business Units to maximize the architectural value of the solutions they design, based on the long-term goals and needs of the business
- Provide inherent, seamless integration to connect all layers and applications. It provides guidance, architectural information that can be used while creating other enterprise architectures or Solution Architectures
Once the reference architecture is in place, the set of architectural principles, standards, reference models, and best practices ensure that the aligned investments have the greatest possible likelihood of success in both the near term and the long term (TCO).
Drivers for Enterprise Reference Architecture
The drivers of the Reference Architecture are, Reference Architecture Goals, Principles, Enterprise Vision & digital Transformation. The details are depicted below diagram.
Fig 1: Drivers for Enterprise Reference Architecture
Enterprise Transformation covering,
- Ever-increasing customer expectations
- Need to retain existing customers
- Pressure to decrease Time-to-market
- Need to be compatible with other products and vendor
- Regulatory Compliance
Enterprise Vision must be,
- Mergers, acquisitions and outsourcing
- Fexible to changing business needs
- Ensure customer satisfaction
- Be adaptable to changes in technology
Architecture Principles addressing,
- Technology Neutrality
- Loose coupling of models
Architecture Goals covers,
- API based service integration
- Enable Service Visibility
- Handle growing complexity
- Enable interactions between models
- Enable better governance and performance
- Cross Ownership Boundaries
Reference Architecture Development Framework
Reference architecture development framework helps manage end-to-end lifecycle of Reference Architectures that Business Units across Enterprise utilize to increase the architectural value of the solutions build for business.
It consists of 5 steps covering Strategy, Preparation, Development, Evangelize and Optimize. The following diagram shows the reference architecture development framework.
Fig 2: Approach to develop Enterprise Reference Architecture
Strategy: For most of the Organizations, architecture Strategy is designed to provide linkage between the architecture and strategic goals, policies, and investments. Strategy helps in,
- Setting the objectives and roadmaps for business improvement and transformation of an organization
- Defining goals for data and information quality, governance and sharing
- Identification of strategic context for the evolution of the business application portfolio through sharing, reuse, and the adoption of common capabilities
As a first step, identification, scoping and prioritization of architecture requirements are done. The architecture requirements cover the business requirements, technical requirements.
Enterprise architecture review board (EARB) reviews the need for the development of new reference architecture and assign the team for the development of reference architecture. Also, the identification of sponsors and their role, responsibilities are defined.
Preparation: During this phase EARB need to identify the contributor team and onboard them to develop reference architecture. Definition and agreement of plan covering timelines and deliverables are arrived during this phase. EARB need to acquire the necessary approvals from the business stakeholders to initiate the reference architecture development.
Development: steps to be performed during this phase are,
- Conduct workshops, meetings & discussions to gather inputs
- Identify contributors & stakeholders
- Coordinate with the Industry domain community for any inputs
- Develop reference architecture drafts in iterations
The following diagram depicts the development of Enterprise Reference Architecture. Business Capabilities, Architecture Principles, Standards, architecture requirements form the inputs for development of Enterprise Reference Architectures.
Fig 3: Development of Enterprise Reference Architecture
The various reference architectures that are commonly developed for an enterprise are,
- Business reference architecture
- Application reference architecture
- Data reference architecture
- Technology reference architecture
- Integration Reference Architecture
- Big Data Reference Architecture
- Cloud Reference Architecture
- Mobility Reference Architecture
- MDM Reference Architecture
- Cyber Security Reference Architecture
- Microservices, SOA Reference Architecture
- Enterprise Content Management Reference Architecture etc.
The above architectures are more technology specific and used to enable the domain specific reference architectures.
Evangelize: During this phase the EARB reviews the reference architecture that developed and take a decision about approval or rejection. Upon the approval, the developed reference architectures are published across the enterprise which need to be followed by the business units/LoBs. EARB need to evangelize solution architecture implementors to adhere to reference architectures to develop best aligned solutions.
The diagram below depicts the Enterprise Architecture Governance team and their responsibilities.
Fig 4: Enterprise Reference Architecture Governance
Optimize: During this phase, development of reference architecture change management plan is done. Any minor updates to the reference architecture are approved by the EARB as needed. However, the major updates to the reference architecture will go through the entire reference architecture development process.
Benefits of Enterprise Reference Architecture
By adopting a reference architecture across the organization speeds up delivery. It also offers a foundation for governance, ensuring the consistency and applicability of technology use within an organization.
- Cost Optimization across Project and Solution Portfolios, by eliminating unused or duplicate investments and assets
- Utilization of shared resources results in Shorter Implementation Time and Cost on the development expenses of software projects
- Enhancement of the software systems’ interoperability
- Improvement in internal communication
- Learning curves of the teams are reduced drastically
Reference architectures would not be considered solutions or potential solutions to the business problem. Reference architectures outline the requirements for achieving organizational goals and objectives.
Reference Architecture is not same as Architecture Framework. It is a template for creating and delivering high quality software products covering data models, relationships between elements, communication protocols, views, processes etc. Enterprise Reference Architectures serve as the basis for disparate architecture efforts throughout the organization, even if they use different tools and technologies. Reference architectures provide best practices and approaches in a vendor, technology, and standards independent way. Reference Architectures model the abstract architectural elements for an Enterprise independent of the technologies, protocols and products that are used to implement next generation architectures.
Reference architectures are only valuable if users across enterprise use them as intended and follow. otherwise, the idea of reusing industry best practices fails. Enterprise Reference Architecture help project managers, enterprise architects, solution architects, designers, software developers to collaborate and communicate effectively about an implementation project.
The author would like to thank Santosh Shinde of BTIS, Enterprise Architecture division of HCL Technologies Ltd for giving the required time and support in many ways in bringing this article as part of Architecture Practice efforts.
Dr. Gopala Krishna Behara is an Enterprise Architect in BTIS Enterprise Architecture division of HCL Technologies Ltd. He has a total of 26 years of IT experience. Reached at firstname.lastname@example.org.