Enterprise Architecture (EA) Principles and their application in an agile environment

How do Enterprise Architecture principles contribute to efficiency and effectiveness in an agile working environment?

The relevance of enterprise architecture principles in an agile working environment

As we all know, agile working environments require a very high degree of responsiveness and agility. Gone are the days when architecture decisions where static with only gradual changes to architecture standards being required. As the possibilities made available by new and emerging technologies increases exponentially and the expectations of the business changes ever more rapidly organisations are finding it ever more difficult to efficiently an effectively maintain an optimal IT landscape that is responsive to their rapidly evolving business needs and strategic objectives. 

This is where the value of enterprise architecture (EA) principles becomes clear. Selecting and maintaining an optimal set of EA principles enables organisations to make architectural decisions that speed up the delivery and maintenance of a high performing set of business and IT solutions. It provides an architectural framework that helps to keep the teams that work on increasingly distributed IT solutions aligned and their IT solutions complementary to each other. This framework of EA principles also helps organisations to ensure that all their IT solutions are driven by each organisation’s individual strategic agenda (business strategy and resulting business goals). 

The most important consideration however is that an optimal EA framework enables organisations to prioritise, design and deliver IT solutions quicker than in the absence of the EA framework. It does this because most of the key organisation-wide architectural decisions have already been made when the framework was last revised, thereby enabling DevOps teams to make rapid progress on their individual IT solutions and services. The EA framework also gives an organisation’s DevOps teams (including 3^rd party DevOps teams) an effective way to collaborate, thereby enhancing the productivity of all the DevOps teams. It achieves this by including in the EA framework principles that enhances the organisations IT solutions life cycle thereby providing a consistent way of delivering IT solutions and services.

What are principles (as defined by Togaf 8.1). 

Togaf 8.1 describes principles as “general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission”. They go on to say that principles are “one element in a structured set of ideas that collectively define and guide the organisation, from values through to actions and results.”

Principles can be established at any or all of three levels: This hierarchy of principles includes:

 

• • Enterprise principles which provide a basis for decision-making throughout an organisation and inform how the organisation sets about fulfilling its mission. In commercial organisations enterprise principles are typically used to align decision-making across the whole organisation and are a key element in a successful architecture governance strategy (see below).

• • Information Technology (IT) principles which provide guidance on the use and deployment of all IT resources and assets across the enterprise. They are developed in order to make the information environment as productive and cost-effective as possible.

• • Architecture principles which are a subset of IT principles that relate to architecture work. These principles describe the level of consensus across an organisation in terms of how the architecture will enable and maintain a cohesive set of complementary architecture patterns. Collectively, these architecture principles describe how the organisation will realise the architecture goals and objectives described by the enterprise architecture. From a Togaf perspective these architecture principles can be further divided into:

     

    • • Principles that govern the architecture process, affecting the development, maintenance, and use of the enterprise architecture
    • • Principles that govern the implementation of the architecture, establishing the first tenets and related guidance for designing and developing information systems

To be effective, each Architecture Principle must align to, and fully support, one or more business objectives and key architecture drivers. Togaf describes 21 architecture principles split into four domains (Business architecture principles, Data architecture principles, Application architecture principles and Technology architecture principles). 

These Togaf principles form a sound basis for establishing the architecture principles needed to successfully establish an optimal architectural landscape given each organisation’s strategic and tactical goals and objectives. They do however need to be developed further given the unique priorities of each organisation. 

 Togaf’s example set of architecture principles.

Togaf provides an example set of architecture principles in TOGAF 8.1.1 Online > Part IV: Resource Base > Architecture Principles This set of 21 architecture principles is an ideal starting point. It provides each organisation with a set of architecture principles that can be used to guide the formulation of their own architecture principles given their unique requirements and strategic agenda. The 21 Togaf architecture principles as provided in the referenced online Togaf documentation are listed below. More information about each principle, such as the rational behind each principle can be found in the referenced documentation.

Togaf Business principle examples

·       Primacy of Principles – These principles of Information Management apply across the organisation.

·       Maximize Benefit to the Enterprise – Information management decisions are made to provide maximum benefit to the organisation as a whole.

·       Information Management is Everybody’s Business – All business units across the organisation participate in information management decisions needed to accomplish business objectives.

·       Business Continuity – The organisation’s operations are maintained in spite of system interruptions.

·       Common Use Applications – Development of applications used across the organisation is preferred over the development of similar or duplicative applications which are only provided to a particular sub-section of the organisation. 

·       Service Orientation – The architecture is based on a design of services which mirror real-world business activities comprising the organisation (or inter-organisation) business processes.

·       Compliance with Law – Organisation information management processes comply with all relevant laws, policies, and regulations.

·       IT Responsibility – The IT organization is responsible for owning and implementing IT processes and infrastructure that enable solutions to meet user-defined requirements for functionality, service levels, cost, and delivery timing.

·       Protection of Intellectual Property – The organisation’s Intellectual Property (IP) must be protected. This protection must be reflected in the IT architecture, implementation, and governance processes.

Togaf Data principle examples

·       Data is an Asset – Data is an asset that has value to the enterprise and is managed accordingly.

·       Data is Shared – Users have access to the data necessary to perform their duties; therefore, data is shared across enterprise functions and organizations.

·       Data is Accessible – Data is accessible for users to perform their functions.

·       Data Trustee – Each data element has a trustee accountable for data quality.

·       Common Vocabulary and Data Definitions – Data is defined consistently throughout the enterprise, and the definitions are understandable and available to all users.

·       Data Security – Data is protected from unauthorized use and disclosure. In addition to the traditional aspects of national security classification, this includes, but is not limited to, protection of pre-decisional, sensitive, source selection-sensitive, and proprietary information.

Togaf Application principle examples

·       Technology Independence – Applications are independent of specific technology choices and therefore can operate on a variety of technology platforms.

·       Ease-of-Use – Applications are easy to use. The underlying technology is transparent to users, so they can concentrate on tasks at hand.

Togaf Technology principle examples

·       Requirements-Based Change – Only in response to business needs are changes to applications and technology made.

·       Responsive Change Management – Changes to the enterprise information environment are implemented in a timely manner.

·       Control Technical Diversity – Technological diversity is controlled to minimize the non-trivial cost of maintaining expertise in and connectivity between multiple processing environments.

·       Interoperability – Software and hardware should conform to defined standards that promote interoperability for data, applications, and technology.

 

A few practical DevOps examples of architecture principles. 

DevOps architecture principles assist the DevOps teams in accelerating their pace and quality while delivering application software. These DevOps architecture principles include:

·       Foster Better Collaboration and Communication – This principle emphasises both collaboration and communication. It is achieved by ensuring that the development and operations teams co-exist in a single functional group, which results in improved communication, feedback sharing, and creating a better collaborative environment throughout the entire development and deployment cycle. 

·       Automation in Everything – Automation facilitates rapid deployment of new software or services to customers, from infrastructure provisioning to building new systems. To ensure high quality and production readiness, a unit and multiple layers of functional tests are employed to find potential issues and regressions in the product. 

·    Improve Performance with Continuous Integration and Delivery – Implementing and practicing continuous integration will support a collaborative environment between the groups, improving overall performance. This is achieved by:

 

• • Maintaining a single code repository. 

    • Automating the process and enabling continuous deployment. 

    • Employing version control. 

    • Securing the whole process. 

     

    • • Collecting feedback regularly. 

·       Impose Shared Responsibility – Adopting this principle enables the DevOps teams of developer and operations professionals to share feedback and knowledge among the team, increasing transparency, improving collective intelligence, and removing constraints. In a DevOps team there should be no distinction between the operations and development teams. 

·    Create End-to-end Workflows – DevOps is a continuous process that comprises all the aspects of business. It does not after delivering the software. 

·       Customer-Centric Action – The DevOps team uses short feedback loops to develop products and services solely cantered on the needs of their customers and end-users. This practice enables rapid collection and prompt response to user feedback via real-time live monitoring. 

·    Embrace Failure and Learn from it – To fully embrace the innovative principle of DevOps, an organisation should embrace to attitude of “failing fast”. Learning from failure and modifying behaviour according to the lessons learnt from failure is the surest way to establish and maintain high performing DevOps teams. This can be augmented by Implementing DevOps automation tools that will allow teams to work more efficiently and bring them together to lead a more cohesive process and culture. 

In WiRD’s experience many early DevOps deployments do not deliver the expected improvements in the Solutions life cycle because they are not supported by a consistent EA framework. What has your experience been in this regard? How effectively has the DevOps capability in your organisation been in its early days? Please share your experiences with WiRD and each other by commenting or interacting on LinkedIn