- In preliminary phase you can tailor TOGAF. it couldn't be done throught the process, only in Preliminary Phase.
Inputs could be organized differently. They could be Reference Materials, Non-architectural and architectural inputs
- ToGAF Library - the all of the documentation, the official standards, the series guides and the other documentation that can go along with TOGAF.
- Other Architecture Frameworks - any other architecture frameworks that you deal with.
- Board strategies and Board Business plans, Business Strategy, IT Strategy, Business Principles, Business Goals, Business Drivers - Anything that comes from your board of directors in terms of business plans, business strategies, IT strategies, what are the business principles that are defined at that level? Business goals and why are we even doing what we do?
- Major Business Operating Frameworks (e.g. SCRUM) - So do you do an Agile development process using Scrum, or what is your what is your business process and what other frameworks are happening?
- Governance and Legas Frameworks, including Architecture Governance Strategy. - any kind of governance or anything that's that you can gather in terms of those areas, partnerships and contract areas and things like that.
- Architecture Capability - an evaluation of your architecture capability.
- It also includes any other documents relating to it, team members and things like that.
- Partnership and contract agreements.
- Existing documents related to architecture capability.
- Organizational Model for Enterprise Architecture.
- And so this is basically what scope of organizations are impacted your gaps:
- maturity assessment,
- budget requirements,
- roles and responsibilities,
- etcetera.
- And so this is basically what scope of organizations are impacted your gaps:
- Existing Architecture Framework.
- Any other architecture, specifically architecture frameworks besides TOGAF that you're dealing with? The gap may be the only one, but maybe you've been doing this before, or you have other architecture frameworks in your organization.
- Define the architecture capability desired.
- Often called "Where, What, Why, Who, and How we do architecture"
- What to do with this?
- Why are we even starting this process?
- Who is involved?
- Often called "Where, What, Why, Who, and How we do architecture"
- Establish the architecture capability including defining your architecture principles.
- Scope the enterprise organizations impacted
- Confirm governance and support frameworks
- Define and establish Architecture Team
- Identify and Establish Archiecture Principles
- Tailor ToGAF and Other Frameworks
- making changes and tailoring TOGAF and any other frameworks: Adding or deleting steps\things
- Implement Architecture Tools
- If you have an architecture repository or a CRM for knowledge management, getting that stuff installed and getting everybody access happens in the preliminary phase.
- Organizational Model for Enterprise Architecture
- It's like the roles and responsibilities, the budget, any kind of constraints that you have, what is your gaps or maturity assessments, etc.
- Tailored Architecture Framework - version of ToGAF ADM process you gonna apply and go through for exact organization
- Initial Architecture Repository
- set up initially architecture repository. It could be empty, but it's not going to be completely empty because you're going to have some of those documentations that were created in the input phase.
- Business principles, business goals, business drivers
- any kind of business principles, business goals, business drivers that goes into the the architecture repository.
- Request for Architecture Work (optional)
- somebody outside your team is going to actually formally ask you to perform this.
- and it's formally written down what it is that they want you to do.
- Architecture Governance Framework
- governance is this concept is about "how you handle change"
- If somebody wants to make a change request, it goes through the governance framework.
- If somebody wants to revise a particular document outside of your team, then there's a whole process for "what do you do?", "Do you stop what you're doing?", "Do you go back to the previous phase?"
- You kind of need a set of people who can make some decisions and everything gets documented.
-
Principles Catalog - this is something you're going to end up living by as you go through the rest of this process.
- Principles hardly ever change.
- Principles make it actually easier to make decisions. It's easy to say no because this goes against my principle.
-
Examples of Principles:
- Might be that you prefer to get off the shelf software,third party software, as opposed to always designing custom software.
- Could just be a preference that your organization has and that could be a principle as well