IT Principle Architects and their role in building and aligning IS architectures (Source Link). Redacted and changed from the source.
Principle Architects or PA’s are very experienced Technically driven Architects, who will mentor more junior Architects. They are not salespeople. There is not a huge difference between Principle Architects and Enterprise Architects or EA’s. An EA may or may not be working with ‘junior’ Architects. Both PA’s and EA’s will certainly be working with Subject Matter Experts or SME’s. No one should expect a PA or EA to be an expert in all areas of IT, nor are they expected to program or build applications (though a good knowledge of both is extremely helpful allowing interaction with engineers and developers). Both PA’s and EA’s are responsible for aligning IS with the Business. Both should be using TOGAF as their framework of interaction.
What Are Enterprise Architecture Principles?
Principles are the rules and guidelines that an enterprise follows. These Principles help organizations to keep everything running smoothly. Principles can exist at different levels throughout the enterprise.
Architecture Principles are the rules and guidelines specific to an enterprise’s architecture. They are a subset of IT Principles. Enterprises use their architecture Principles to govern their information management systems and any other IT tools.
TOGAF, The Open Group Architecture Framework, has laid out an example set of 21 high-quality architecture Principles.
There are a few things you will notice about the TOGAF Principles.
First, a TOGAF architecture Principle is divided into 4 parts. A TOGAF Principle always has a:
- Name – Clear, precise, and easy to remember.
- Statement – Generally one sentence in length. Clearly tells you what the Principle is.
- Rationale – Explanation of why the Principle is important and how it will benefit the business.
- Implications – List of what is required to successfully carry out this Principle and how it could potentially impact the business.
Of the 21 Principles, there are four different domains (or subsets) of TOGAF architecture Principles:
- Business Architecture (deals with your business strategy and organization of business processes)
- Data Architecture (deals with the management and structure of data resources)
- Application Architecture (deals with individual application systems and how they work with each other)
- Technology Architecture (deals with tech requirements that are necessary to keep the enterprise running smoothly)
Each of these subsets contains specific enterprise architect Principles regarding that domain and its operations. We’ll be looking at some of the most important examples below.
How Many Architecture Principles Does an Enterprise Need?
In general, you should aim for 10-20 guiding Principles for your enterprise architecture.
If you have too many architecture Principles, it will limit your architecture’s flexibility. Too few, on the other hand, leads to generic statements that can’t be implemented in a practical, real-world way.
Out of the 21 TOGAF architecture Principles, there are 9 critical Principles.
1. Maximize Benefit to the Enterprise
All decisions about information management MUST be made based on the benefit of the enterprise.
That means that sometimes, what feels best for one organization within the enterprise might not be what’s best for the enterprise as a whole.
All individuals and organizations within the enterprise must be willing to work together, following the guiding Principles, for the maximum benefit of the enterprise.
2. Information Management is Everybody’s Business
This TOGAF Principle states that “all organizations in the enterprise must be involved in all aspects of the information environment.”
Basically, this is another Principle about the importance of working together across an enterprise. Everyone needs to take responsibility for doing their own part in managing information and participating in important decisions.
This means that the PA must have a ‘Stakeholder Matrix’ and identify what each stakeholder wants (from the project or use case), what the business really ‘needs’ and what issues may arise if there are impedance mismatches within the Stakeholder Matrix.
3. Business Continuity
This Principle states that “hardware failure, natural disasters, and data corruption should not be allowed to disrupt or stop enterprise activities.”
Disaster Recovery and BCP (business continuity plans) must be documented, tested and in the case of Data BCP (backup, replication), enacted.
4. Data as an Asset
All data is a concrete, valuable asset to an enterprise. It is a real, measurable resource.
Because all decisions in an enterprise are made based on data, all that data needs to be carefully organized and managed. Everyone in the enterprise should know that their data is secured, reliable and accurate.
They should also know how to access relevant data whenever they need to.
5. Data is Shared
This Principle says that data should be stored within one application and shared across the entire enterprise. This is important so that everyone within the enterprise has access to the data they need to do their job.
Storing all the data within one application is much cheaper and easier than storing it in different applications.
6. Data is Accessible
This one means that everyone in an enterprise needs to have easy access to all data within that enterprise. This makes it easier to do their jobs.
One of the “implications” of this Principle is that there needs to be some flexibility to make sure that all the different people of an enterprise are able to access data in a way that best works for them.
You can see that these three Principles all tie together closely: data is an asset, data is shared, data is accessible.
7. Ease-of-Use
All technology within an enterprise needs to be easy to use.
The more time you spend trying to figure out how to use technology, the less time you have to spend on your actual task. That means less productivity and lower concentration — never a good thing.
Keep the technology simple, so that everyone can do their jobs efficiently and effectively.
8. Control Technical Diversity
Although there will necessarily be some different technical requirements for the various applications across an enterprise, this Principle states that you will try to keep the different technologies to a minimum.
The more different technologies that you throw into the mix, the more expensive and troublesome it gets for your enterprise.
9. End User Impact
End Users must not be negatively affected or unable to do their jobs caused by project work, poor implementations or system and systemic failure. Understanding End Users as stakeholders, and bringing them into the technical process and project, is important. Having a clear goal of not disrupting their work sets a clear boundary on what technical work should be done. This Principle is a higher order Principle and must be prioritised.