theknowledgeacademy

TOGAF® EA Practitioner Unit 1

This first unit looks at the concepts of enterprise, architecture and TOGAF, and it's
drawn mainly from the part zero of the token standard fundamental content
that's the C 220 document but it also draws on information from Part 5 as well.
The enterprise architecture capability and governance as well as a number of
series guides, in particular CHIP 186, which is the series guided practitioners’
approach to developing enterprise.
Architecture following the TOGAF Adm enable enterprise agility, which is due to
20F.
Integrating risk and security within autograph enterprise architecture which is
G152 and using the total standard digital enterprise which is G27.
So, drawing information from a number of documents. We'll have a look at
guiding effective change, the purpose of enterprise architecture, what does an
enterprise architecture look like, architecture, capability, architecture,
governance and the role of an enterprise.
Architect architecture compliance levels of performance reviews and the role of
the architect and have an architecture enables alignment to organisational
objectives using agile development as an example.
Also have a look at the need to manage multiple architecture states, enterprise
architecture and enterprise security, architecture and security and cross cutting
concern. Manage your uncertainty in order to optimise maximum business
benefit.
Business loss. The enterprise architect and the Enterprise architecture in a digital
enterprise, so guiding effective change the purpose enterprise architecture it's all
about managing or guiding change.
Enterprise architecture EA is developed for one simple reason to guide effective
change, whether that be change at the very top of the organisation. Whether that
be changed within a particular area of the business.
 theknowledgeacademy
It depends on the overall sort of level of architecture. Scope as to what exactly
the change will entail? Guides or effective change takes place during the activity
to realise the approved EPA during implementation, EA is used by the
stakeholders to go and change our enterprise architecture guides effective
change and architecture approach provides some rigorous planning and change
governance methodology. Enterprise architecture facilitates effective governance,
manage.
And risk management and exploitation opportunities. It describes the future state
and the current state of the enterprise.
So, the, the baseline and the target architectures, the gap between the
enterprises, current state and future states, highlights what has changed that
gives us the requirements.
Once we worked at the gap between the baseline and the target. What does an
enterprise architecture look like? It's a. Set of model’s components. And their
relationships that comprise the scope of the EA landscape and the construction
consideration.
It exists to guide and constrain change planning and work to perform the change.
The scope of work embedded in a request for architectural work to identify the
applicable characteristics of the EA landscape.
Models consistently describe the current and targeted architectures. Primary
purpose is to facilitate the architect to understand the system being examined.
Secondary purpose is reuse. If we've got a well-structured architecture repository,
then within that repository.
You should have an area that content could be put forward use because when
we're talking about reuse, it's not just about reuse of this this capability we use of
applications we use of data we use of technology, but it can also be about reuse
of your architecture documentation. You know someone's gone to the effort of
creating an organisational decomposition.
Diagram and then somebody else in another project need an organisation
decomposition diagram for the same part of the organisation. Then it makes
sense that there should be a process is in place that allow the reuse of content,
 theknowledgeacademy
notwithstanding the need to restrict certain content based on its the content on
its confidentiality.
AKA EA capability, sometimes referred to as an EA practice. In order to carry
out architectural activity effectively with an enterprise, it's necessary to put in
place an appropriate business capability for architecture through organisational
structures role, which responsibility, skills and processes.
And EA capability is the ability to develop, use and sustain the architecture of a
particular enterprise.
And use the Architecture to govern change EA capabilities used here as a
management concept that facilitates planning improvements in the ability to do
something that leads to enhanced outcomes, enabled by the capability.
For purpose a capability model, we can have enterprise architecture capability at
various levels. We've got an EA to support strategy, so deliver EA to provide target
architecture and develop Rd maps for change. It says they're over a three to 10-
year period.
That might be the Case in some organisations that it might say might see three to
10 years of being strategic, but in other organisations it could be that it could be
deemed or viewed as strategic.
If it's just, you know, a couple of years. If you're more typical sort of projects are 6
to 9 months, then then two years could be seen as sort of strategic so.
You know, obviously they decided, you know, whoever came up with these
definitions that that three to 10-year period was more sort of strategic, but then
they don't necessarily say that for portfolios or any sort of one to two years
because you can still have a portfolio of change across a long period.
E to support Portfolio delivery aid to support cross functional, multi-phase and
multi project change initiatives EA to support project deliver EA to support the
enterprises project delivery method and EA to support solution live.
Every delivery a that is used to support the solution deployment and we might
have seen previously, the concept of an architecture landscape where we had
 theknowledgeacademy
strategic and segment and capability architecture and that sort of fits in here,
although there are four different purposes.
You could join the sort of the last two together to a certain extent and in terms of
solution.
Delivery you're looking very much at supporting the implementation, the phase,
the Phase G of a capability architecture project with the you know supporting the
project.
Within that as well and then the portfolio would be more synonymous with what
they might refer to as segment architecture?
And of course, the strategic level for strategic architecture and when we have this
potential sort of hierarchy of purpose capabilities, then the moving from sort of
left to right.
We start at the very Sort of top and then work our way down.
Now, as you would expect, the lower levels will look to the upper levels for
guidance in terms of consuming the superior architecture, but then also
governing the subordinate architecture and you can see that as you go through
from left to right from strategic the portfolio to project and then eventually to it's
a solution.
Architecture, governance and the role of an enterprise architect. The ISO defines
governance as a system that directly controls the current and future state.
Governance is a decision-making process with the defined structure of
relationships to direct and control the enterprise to achieve stated goals. And if
you've got this hierarchy of Architecture capabilities. Then you would expect to
have a hierarchy of governance.
With the implementation governance being talking primarily about the
architecture team providing governance at the implementation level, but of
course within the implementation you could have further governance in terms of
the Planning framework governing the actual projects and programmes so you
can have various layers of governance there you've got the main Governance,
business, architecture, governance and EA governance and corporate governance,
 theknowledgeacademy
and within your EA governance, you might have various sort of layers, whether it
be strategic or segment or capability architecture. So there's often various layers.
When it comes to governance do distinct things must be governed and supported
by the enterprise architect, the development of the target architecture and all
changed within the scope of the target architecture.
Enterprise architect role supports the organisations leadership, directing and
controlling change through the governance of the development of the targeted
architecture. Governance have all changed and the scope of the target
architecture enable enables to do up a good target that provides an organisations
best achievable course to go forward.
Typically, the enterprise architect and the implementer are directed and both are
controlled by the stakeholder. There is very much an emphasis in in TOGAF 10 for
the Stakeholders would be very much the one that's making the decisions, and
certainly from what we've seen of the practitioner.
Albeit you know fairly limited at the moment, there seems to be very much that
emphasis on the stakeholder, and if you've got a practitioner question and it's you
get an answer which is very much sort of highlighting the stakeholder as being
involved in decision making.
Then that's, you know, more likely to be the answer. Or conversely, if you get a, if
you've got an answer where it talks about the architect primarily making decisions
without you know.
Having you know Recourse to what the stakeholders want, then that's less likely
to be the best answer, remembering of course that the answers for the for the
practitioner exam on a sliding.
Scale you'll see this if you get to have a look at the learning studies at some point
because the exercises there are very similar to the to the practitioner.
Questions and there was very much an emphasis there on making sure that you
understand what the stakeholders require, architecture compliance levels of
performance reviews and the role of the architect ensuring the compliance of
individual projects within the enterprise architecture is an essential aspect of
architecture governance.
 theknowledgeacademy
Usually 2 complementary processes. The architecture funds will be required to
repair a series of project architectures and the enterprise and IT governance
functions will define a formal architecture compliance review process for
reviewing the compliance projects.
Levels of conformance, the key relationship between the architecture and the
implementation lies in the definitions of the term’s conformance, compliance,
etcetera.
While terminology usage may differ between organisations and concepts and
levels of conformance illustrated in the figure. On the right here should prove
useful in formulating an IT compliance strategy.
We're talking here with the implementation in Phase G, so in Phase G we as
architects would typically be carrying out performance reviews to make sure what
has been implemented meets the specification. And in the example, we've got
here, the blue circle, the architecture specification is what we would.
In the architectural requirement specification document and the yellow circle
indicates what was actually implemented.
Whether you end up with terminology, that's exactly the same as. This remains to
be seen whether you'll have something that's. Sort of similar issue. With certain
terminology, again, that's up to you to decide.
Is a bit of guidance and they what you can say here is they've tried to sort of cover
all eventualities where they're looking at.
First of all, has a has a feature or function implementation in terms of? Maybe we
wanted a couple of features being implemented at a certain point within the
implementation.
Have we got those features and then have they met the measures in the
architecture specification and that then gives us the?
Variance in terms of the different outcomes. But it is a bit of guidance and you
know, you don't have to do it exactly like that. You might have your own schema.
Architecture Compliance Review is the scrutiny of the compliance of a specific
project against established architectural criteria, spirit and business objectives,
 theknowledgeacademy
formal process for search reviews normally forms the core of an enterprise
architecture compliance strategy and you've got 22 main sort of compliance
reviews. One is the architecture team checking in phase three to make sure that
the implementation specifications and you can also have a compliance review in
Phase H where the Architecture Board set effectively and they cheque upon the
performance of the Architecture team at various points in the project. Target
checklist used to execute architecture.
Governance and we stakeholders can approve architecture implementation and
other change checklist designed to assist the practitioner to understand what
must be demonstrated during the governance process to address a
noncompliance report.
In terms of the target checklist, the last question says have the stakeholders
approved the views? If the answer is yes, then the governments process is there.
If the answer is no, then there is a decision on whether the practise should rework
the architecture or the architecture project be cancelled. That would be the
possibility, or maybe slightly extreme, but if the stakeholders aren't happy, then
again that sort of emphasises.
The whole sort of we need to make sure that the stakeholders have agreed what's
being created as far as the target is concerned and if they're not happy then it
might be a case that we have to stop the role of the architect in Architecture
Compliance, 2 role governance roles were often performed.
The auditor and the architect Compliance assessment is an auditor role where
non compliance is identified. The architect needs to produce an impact
assessment and recommendation on what to do.
The impact must be assessed on the same terms as the target has developed
assessing on any other terms and validates the assessment and recommendation.
Our architecture enables alignment to organisational objectives using agile
development as an example.
Don't have these. Agile development is very much fitting in into phase three, so
it's that's agile development alliance with Phase G implementation governance.
 theknowledgeacademy
A good architecture developed in phases A to F will identify what products the
enterprise needs the boundary of the products and what constraints the product
owner has. Architecture will have a set of constraints that limit the trace off the
agile team, often termed as guardrails. So even when you're. Down at the lowest
level of architecture.
You typically don't have the detail necessary for implementation, so one of the
first things that will occur in phase G would be some low level design. Typically
using something like agile and what they what they're saying is that the TOGAF
provides the constraints on that and child development that, yeah, provides these
guardrails as those are referred to them here as an example, if you were putting a
saying ERP system in place and she wanted to have as part of the.
The installation and improved order process that could be an architectural
requirement and the measurability of that could be that, provided that the
process takes no more than 20 steps of process in order, then it is vastly improved
on what?
It was previously So that would then provide a guard rail a constraint.
On the actual development because from an architectural perspective, we don't
know exactly what's involved in processing an order. That's where the actual
development would come in and say, well, OK, it's all very well saying that, you
know, if it takes less than 20 steps, then we're happy.
But there's still Got to be the you know, the right steps to. To process an order.
but from an architectural perspective, we're not specifying exactly what the steps
are. We're just turning around and saying look, you know.
If it's less than 20 steps, we're happy and that then provides the Guard really in
that in that particular instance.
Focus on risk mitigation. The practitioner needs to provide support for the change
activity. There should be a focus on risk mitigation to ensure that the project
meets its objectives. The practitioner needs to act as the stakeholder’s agent.
When it comes to risk in toe gaff just as sort of a bit of a heads up.
In that it's sort of fairly stand Risk management, with the exception of the
terminology where you'd normally refer to risk in terms of its probability and
 theknowledgeacademy
impact in terms of if they use the terms frequency and effects on the, it's just a bit
of a sort of you know.
If you go through the documentation and you come across. The term risk with
related to risk and he's talking about frequency.
You might be thinking well, what's that about? That's the term that they decided
to use instead of probability.
I mean, personally I would use probability in the vast majority of situations.
Although I have seen frequency used in relation to mathematics and statistics.
They need to manage multiple architecture states.
We have the current or baseline, so where we are, what we've got in.
Place candidates transition and candidate target architecture.
So they're an approved transitional target, architectures, working hypothesis, the
transition and target state. What you have or what you'll get eventually in Phase F
when the architecture is approved, the target where the current, the time horizon
of architecture development ends, that's an approved.
Target states there may be a new target later and transition it says reasonable
places between current and baseline and target, where it's possible to stop
further progress and gain value. So, if you were, you know.
Planning on implementing a new ERP system in the UK across various sites. It
could be that having completed the implementation in a particular site that could
then actually provide a transition architecture point. Whether it's actually
possible to use the new system if that were to.
Be the case remains to be seen, and whether you'd actually get value from it
would in some cases.
Remain to be these are just sort of, you know, ideals. You know, sometimes you
have to have transition architectures based around implementation constraints
and.
Information projects and it doesn't necessarily fall in line that we would, you
know, we have to gained any, you know, discernible value until we've got the
whole of the transformation completed.
 theknowledgeacademy
Practitioners track the architecture states across 2 characteristics, time and the
performance test tracking performance facilitates the implementation, project
and operational change governance.
Managing complex Rd maps complexity increases when you add in the four
characteristics of the EA landscape, breadth, depth, time and recency, and the
different architectural projects that can work on the same subject at different
times and at different levels of detail.
Additional factors that can add to the complexity, advanced advancements, and
changes outside of the enterprise.
Anything that we don't have direct control over can be seen as obviously a risk
that transforms.
And as you know, complexity, shared services, collaboration with suppliers and
partners including portfolio ownership model, impenetrable dependencies. So
sometimes you know you just have to do things in.
A certain order because of the dependencies, multiple geopolitical boundaries.
Just from calendars, Regulations, cultures, varying rates of maturity, growth of
teams, EA team model, Federated, centralised, et cetera and available.
Availability of multiple solutions or announcement of end of life products can all
add to the complexity.
Enterprise security architecture, essential security and risk concepts and their
position in the token FA. Yeah. What we can see from this graphic is that security
is throughout the whole of the idea pretty much.
And that's why they, tend to refer to it as we shall see shortly. As a cross Cutting
domain of cross cutting concern because we can have. Business architecture,
security and data architecture, security and application security and technology
security. It's not just in in one domain area.
They used to provide security guidance back in TOGAF for 9.1 days, and then they
decided to remove that security guidance from the TOGAF standard for, for
TOGAF, 9.2 and started to align themselves to the security guidance provided by a
 theknowledgeacademy
third party organisation called Samsa is the Sherwood applied business security
architecturesapsa.org if you're interested.
In going having a look there, but there is this Series guide, which is G217-G152,
which is integrating risk and security.
In Autograf enterprise architecture, which is largely based around the SABSA
guidance.
Security architecture, the structure of organisational, conceptual, logical and
physical components that interact and coherent fashion in order to achieve and
maintain the state of managed risk and security.
To both a Driver and a neighbor of secure, safe reliant and reliable Azure as well
as for addressing these areas throughout the enterprise.
Enterprise security architecture does not exist in isolation. As we're saying before,
it's going to be very much into over with the other architectures post integration
of security architecture in the enterprise architecture is beneficial, builds on
enterprise information that's already available in the enterprise architecture and
produces information.
Doing it right the first time saves costly and increases effectiveness compared to
bolting on security afterwards, so it should be a consideration at get go, not
something that you go right will develop this 1st and then.
Think about it in the later date. So therefore, it is very much a cross cutting
concern. The TOGAF Adm covers the development of the four architecture
domains, so business data, application technology and then the security
architecture interacts with all of them and is therefore referred to as cross
cutting.
Managing uncertainty in order to optimise maximum business benefit and
minimise business loss, risk and uncertainty risk is the effect that uncertainty has
on the achievement of this objectives.
Uncertainty typically involves A deficiency of information and leads to inadequate
or incomplete knowledge or understanding. The uncertainty is concerned with
predicting.
 theknowledgeacademy
Neutral outcomes, given the limited amount of information available when
making business decisions, this information can never be perfect. All our
expectation is that give a better-quality information. We can make better quality
decisions.
Decision making based on risk management. It's very much like getting the
balance between potential opportunities and threats. The likelihood of beneficial
outcomes versus damaging outcomes.
The magnitude of these potential positive and negative events and the likelihood
associated with each outcome identifying the session these factors is known as
risk assessment or risk analysis. Risk management is the art and science of
applying these concepts in the decision-making process.
This can be seen at the strategic long-term level, overall direction of the business,
the medium-term tactical level transmission projects and programmes and at the
operational level, regular data and operational.
Decisions, processes and practises the objective of risk management is to
optimise business to help comes to maximise the business value and minimise
business losses.
Anything which we don't have direct control over is normally seen as being a
bigger risk because of the fact that we don't have direct control over it, so
external factors will often be a much bigger risk than something we can internally
we can control.
This can be seen at any level in the business Stack, but it's always driven top down
from assessment of the business value and its optimization and that's the
business risk versus the cyber risk areas as shown there from the Sampson you
don't need to know any particular detail, certainly from the certification
perspective, but it's just showing you there the risk of across the business
application, date data and technical components.
The enterprise architect and enterprise architecture in a digital enterprise. The
information contained here has come primarily from the G217, which is using the
total standard in the digital enterprise.
 theknowledgeacademy
This particular graphic is showing the sort of four major contexts that the world
will discuss very shortly, it's based on information from the United States.
The percentage numbers are the percentage numbers of United States businesses
that have this number of employees and these are the sort of four plateaus you
you've got the organisations that might fit into the sort of curves.
But then you've got the sort of Plateaus of founder being one to three employees,
team typically being 8 to 12 employees, team of teams 40 to 70 employees and
Enterprise 3 and 50 to 500 Employees with a turnover greater than the 50 million
U.S. dollars.
Whether you know you have an organisation that's got say 200 employees, is that
really a sort of enterprise or enduring enterprise as opposed to a team of teams? I
don't think really matters. Ultimately, these are just sort of targets sort of figures.
Not necessarily absolute, but it's interesting that according to their data, 96% of
the US organisations falling to the founder context.
So, lots of small organisations and very small percentage of the team of teams or
enduring enterprise.
OK.
The individual founder context addresses minimal essential concerns that they
must address to develop and sustain a basic digital product. This context
represents the bare minimum requirements delivering digital value.
In the individual founder context, the architecture role. Primarily uses
communication medium, so architecture models communicate very well.
It provides the necessary descriptions to communicate the infrastructure
available and its appropriate use for both development and delivery use to
support and provide answers to questions about agile development and
continuous delivery.
The architect role is to act as a communicator, we considered a key enterprise
Networker, helps to identify existing infrastructure approaches that may be
embedded in large organisations and to communicate vetted technical
requirements to the infrastructure organisation.
 theknowledgeacademy
To ensure preparation for new workloads can be approached to provide guidance
in these areas on demand based on their practical experience context.
To the team slightly larger organisation. So, the team has a single mission and a
cohesive identity but does not need a lot of overhead to get the job done.
The context covers the basic elements necessary for a collaborative prop.
Team to achieve success while remaining at a manageable human scale.
Establishing team collaboration as a fundamental guiding value is essential to
successful digital product development.
The team is all in the same location and can still communicate informally, but
there is enough going on that it needs a more organised approach to getting.
So, in the context to the team, the role of the architecture and the architect, the
architecture role can assist product management by providing models that map
to a given digital product profile, it makes independencies explicit pursuing a
holistic view of the digital product used to depict processes and workflows in a
very simple, simple to very complex level of detail.
Provoice models to depict how the operations are expected to run. So in terms of
the target, the architectural role can ensure efficacy of communication and
collaboration helps to communicate risk and mitigation able to deliver support in
an on demand service oriented manner to meet the operating tempo of the team.
Context 3. The team of teams is a natural evolution of the team’s context but one
where the number of people and digital products involved, great generates
complexity coordinating across the team is one of the main concerns.
Across the team of teams, communication is again key to ensure successful
collaboration and value delivery.
Architecture role helps to resolve concerns related to cultural issues in more
complex organisation, so this is much more of the sort of portfolio level used to
depict portfolios of products, processes and control mechanisms, and to identify
and eliminate choke points for continuous process improvement.
Use of debit independencies and value generation costs and support supports
folio management decision making.
 theknowledgeacademy
Architect role continues to ensure that risk is understood and communication is
effective, ensures that the digital products work together, leverage each other
and appropriately coupled, thus modelling and documenting the move from a
significant from a specific digital product to portfolio of products that require talk.
And then the enduring context, the enduring enterprise context, rather, is about
how to manage an enterprise that has been successful is now faced with the
realities of operating sustainable business over periods of time, longer than you
expect longer than the next product cycle architecture role helps managing risk.
Void on information management through data and application architecture and
the architect role to support the ensuring enterprise and operating sustainable
business over periods of time, longer than the next product cycle.
Now, if you have the Learning studies documentation available. There are some
exercises associated with this particular unit and we haven't had a look at the
studies document yet, so let's go and see what it's all about.
So, we go in here and we have a look at the Telegraph certification for people
enterprise architecture practitioner learning studies question book.
What you've got is an overall case study and this is the, the, questions that you've
got are very similar to a practitioner. Questions in that they have.
A small scenario and then they have a question and then 4 answers and the only
real difference is that all of these learning.
Studies are related to one overall case study, whereas in the practitioner exam
there would be individual case studies as such.
And you can see there that there are varying number of questions for each of the,
units.
So, we've just done Unit 1. So, it's talking about the context for enterprise
architecture.
What you need to do, of course, is to read the case study first, and it's just
reminding you that for each of the scenarios that you get, the best answer will be
worth 5 marks. The second best will be worth 3 marks, the third will be worth 1.
 theknowledgeacademy
The distractor with 0 so you have to decide which one that is the best answer and
it says at the bottom there you should aim to achieve a total of 54 points out of a
maximum of 90 points.
So, you've got more questions here than you would get in the actual exam that
you only have eight questions in the in the exam. But it just gives you an idea of
what sort of what to look out for.
You've also got, the official practise test from the from the open group that you
can also do after the course.
So, what you'll need to do is to read the overall case study, and I would say, you
know, spend about 10- or 15-minutes reading that and then you've got.
For questions related to this first unit, allow yourself 10 minutes per question
because that will give you an idea of the timing that you would have.
In the practitioner exam, and then once you've gone through that cheque, your
answers against the answers in the answer booklet they are.
Pretty detailed and explaining why you know.
A particular answer is the best or why it's not the best.
You can, decide to just work out what you think the best answer is, and then just
leave it at that. Or you can work out what you think the best answer is, and then
the second best, and then the third and so on. If you want to sort of rank the
answers.
It's entirely up to you, but it gives you a pretty good insight into the sort of thing
that you really encounter in the practitioner exam.
 theknowledgeacademy
TOGAF® EA Practitioner Unit 2

In Unit 2, we're going to have a look at stakeholder management.

This entails looking at how to identify stakeholders, their concerns, views and the
communication involved the use of architecture, views, stakeholder engagement
requires management and using trade off to support architectural development,
how do we invite stakeholders, their concerns, views and the communication
involved don't have standard uses.
It takes a formal modelling approach to understand stakeholder concerns and
views. This is a ISO standard that Togaf relates to terms of stakeholders and views
and concern practical perspective.
The practical perspective is in the ADM Practitioners guide, that's the G186 series
guide a practitioner's approach to develop enterprise architecture following the
Telegraph ADM.
Stakeholders are defined as someone who has approval rights in the target
architecture being explored by the current architecture project and subsequently
has decision rights to the suitability of the implementation.
A little bit more specific than it might have been previously, and that's reflected in
the fact that the emphasis is very much on understanding what the stakeholders
want and then making sure that we produce the architecture to meet those
requirements so they have the approval rights, they have the decision rights.
Our concern is a consistent set of subjects that capture this stakeholders’
interests and act to consolidate requirements and the view is of representations
of keyword.
There is representation of the EA landscape that addresses the set of stakeholder
concerns, either describing how the architecture addresses the concerns or
demonstrate in how the associated requirements are met.
 theknowledgeacademy
Concerns from a practical perspective, we consider a concern to be a topic
concern. Addresses the stakeholder’s power, interest and requirements against
the topic.
This approach services topic-based decision rights and provides ability to perform
a tradeoff between competing requirements.
Consistent set of cores concerns aligned to enterprise priority facilitates a focus
on priority recommendations to create a stakeholder concern matrix, common
stakeholder classes, common concern classes, and stakeholder responsibilities
portfolio, including in the course handouts.
If you go and have a look at the course handout, we can see there talks about
stakeholder matrix common stakeholder classes.
The senior leaders bit there in the handout needed to be in bold because it's one
of the classes. This responsibility includes approving and realigning strategic
initiative.
Tracking a portfolio of projects ensuring transformative benefits are realised and
meeting operational business goals, programme and portfolio managers service
responsibility for managing oversight of strategic initiatives.
Responsibility includes approving and realigning projects, tracking project
progress business requirement and as those responsible for identifying and
expressing business requirements, typically in stakeholders responsible for some
aspect of business operation.
Implementers, those responsible for developing, integrating and deploying the
solution, typically from our planning framework. This covers those associated or
interested in a particular risk business partners, those who are engaged to
provide services, sustaining a customer value proposition and then customers are
those who consume products and services, know the architecture may not be
provided to members, but may must be evaluated from their perspective.
What's the agility of the architecture to adapt to a future unanticipated change
efficiency? How do some aspect of the architecture contribute to efficiency of
operations differentiation? How does some aspect of the architecture?
 theknowledgeacademy
Stress enable the differentiation value. What's the value of the architecture, value
proposition change, cost change impact, alignment, feasibility and so on. It's all of
them. But there are various concern classes and then we've got there an example.
It says the table stakeholder responsibilities and it shows the various roles that
we've got there, so senior leaders, portfolio managers, business requirements,
owners, implementers, risk owners, business partner, customer and then the
different areas that there were concerns they might be interested in.
It is just a bit of a guy and she might sort of you know, agree or disagree with
some of that, but it's there. As an example of relating the stakeholders and their
concerns views and viewpoints.
Views simply addresses the stakeholders concern about an architecture, views of
the representation, very much a point in time representation.
Often, it's a potential architecture and the view serves to help the stakeholders,
potential target and associate and associated change, allowing the stakeholders
to put things in context and have confidence about the target and the change
when the stakeholders understand the architecture, the change and the trade-
offs. Implementation governance is possible.
Each viewpoint should identify the concern, the stakeholders, how the view
should be constructed and the information required to address the question. So
the viewpoint is very often referred to as the you know defining the perspective
from which the view is taken and another term.
That they often see associated with viewpoint is a template, so we want a
template for creating the view and then the view is the representation that the
point in time representation.
The use of architecture views the choice of which architecture views to develop is
one of the key decisions that the architect must make responsibility for ensuring
the completeness of the architecture and the integrity one thing that isn't
particularly highlighted here is the fact that the view could consist of 1 or more
artefacts.
We often tend to think of a view as just a single diagram or a catalogue or a
matrix, but it could be a combination of artefacts that are required to address
 theknowledgeacademy
certain stakeholder concerns and therefore in a view, could be made-up of certain
number of artefacts related artefacts.
It says simpler airport system it will go along with it. It says the pilot has one view
of the system, the air traffic controller has another.
Neither view represents the whole system. The perspective of each stakeholder
constrains how they see the overall system. Questions name some elements in
the pilots view not viewed by the controller name.
Elements in the controllers view not viewed by the pilot and name some shared
elements, so take a few minutes just to think about what the pilot might be able
to see, what the air traffic controller would be able to see, and then any sort of
thing that's common between the two architecture views 1 architecture view can
be developed from the viewpoint of the pilot which addresses the pilots concerns
equally.
Another view could be developed from the viewpoint of the air traffic controller.
Neither architecture view completely describes the system in its entirety, because
the architecture viewpoint of view stakeholder constrained and reduces how each
sees the overall system and as of said previously you, you could have a view you
know very high-level stakeholder could have a view where they're just seeing you
know how a system fits in with other business capabilities. But they don't want
any detail? Whereas somebody from a very technical background, maybe a data
analyst.
I want to see the data flow through the system. Exactly the same system, but very
different views because the stakeholders got very different viewpoints and in this
particular instance the architecture viewpoint of the pilot comprises some
concerns that are not relevant to the controllers, such as passengers and fuel.
While the architecture viewpoint of the controller comprises some concerns.
Not relevant to the pilot, such as at the planes. Now I would argue that the pilot is
very much concerned about other planes. If it had said such as other planes not in
the mediate vicinity of the pilots plane, that might have been you know just as
relevant to the that you know, such as other planes, I think other planes are very
relevant.
 theknowledgeacademy
It would have been, you know, as I say, slightly better if it had said, such as other
planes not in the immediate facility, because of course the controller see planes
that might be 50 miles away or 100.
Miles away or whatever, and that's not a particular interest to the to the, you
know, the pilot if they're approaching the airport, or if they're still on the ground
at the airport.
Obviously there's up on the ground they're going to be interested in aircraft that
are, you know, maneuvering and around where they are.
And any, you know, aircraft that might be coming into to land but not so much
those that you know are 50 miles away that you know 100 miles away that the
controller can see, but they're never going to sort of be bothered with because
they've taken off or landed or whatever in the interim.
There are also elements shared between the two architecture viewpoints such as
the communication model between the pilot and the controller and the vital
information about the plane itself.
So there will be commonality, but there will also be elements that you know one
or the other would be interested in. Fortunately, when controllers talk with pilots,
they use a common communication language. Well, in most parts of the world
anyway in other words, the models representing their individual architecture
viewpoints partially intersect.
Part of this common language is about location and vectors of aircraft, and is
essential to safe tools exist to assist stakeholders, especially when they are
interacting with complex models such as the model of an airspace, yeah.
Or the model of air flowing when stakeholders use common tools such as the
radio contact between pilot and controller are common. Language is essential and
in in practical terms. Getting away from their air.
Their airspace sort of metaphor. When you're communicating with stakeholders,
it is important that you create output. You create content that is understandable
to them. Yeah.
 theknowledgeacademy
One of the big mistakes that people often make, particularly those that come
from a more technical background is assuming that everybody wants technical
detail about every and I've seen it in. The past where people have.
Spent hours crafting beautiful, intricate, detailed technical drawings, and when all
the stakeholders wanted to see was just a box which just literally said ERP system
or whatever it happened to be, they didn't want all the detail that they've gone
into but on the other hand, there may be, you know.
The stakeholders that do want to see that technical detail at some point, so it's
very important that you understand the viewpoint of the stakeholders before you
start creating the view stakeholder engagement and requirements management
don't have framework, places, requirements management and stakeholder
engagement at the centre of Architecture Development practises to develop EA in
accordance with the preferences and priorities of their organisation stakeholders.
So again, very much that emphasis on what do the stakeholders want
stakeholders own the architecture and the value, preference and priority that the
architecture is expected to enable good practitioners are passionately engaged in
the future of their organisation as well as participating in defining and realising
the target state.
They typically perform several roles. They might act as a SME, a subject matter
expert and agents for the stakeholders. In addition to developing the architecture
as an SME, the practitioner as a source of expert advice, as an agent, the
practitioner may speak on behalf of a stakeholder requirements management.
Effective requirements management is dependent on clear traceability from the
organisation vision, the mission, the business models, the strategies through to
the most detailed statement of requirements. Requirements management is very
much at the center of the ADM process.
Effective engagements based upon effective communication.
That's based on the concept of the view and the viewpoint, so making sure that
we get the right views created based on understanding the viewpoint. Different
stakeholders have different concerns about the architecture.
 theknowledgeacademy
These concerns must be addressed and represented effectively to the stakeholder
to enable the stakeholder to approve the target using tradeoffs to support
architectural developments that can sometimes be more than one alternative in
terms of target and the information feeding into the decision process will be
vision and principles and requirements and their various criteria and alternatives
and selecting alternative, the first part of the method uses the vision principles,
requirements and other information to select sets of criteria area fitting for
different alternatives.
Second part defines your alternatives based upon the criteria and builds
understanding of each and then the third part will either select one of the
alternatives or else combined features from more than one to create the
proposed alternative.
I'm only talking about sweating and creating the alternatives, it's still very much
down to the stakeholders as to what they want and what their preferred
alternative would be we can just offer them, you know, potentially multiple
solutions, But it's still their choice.
The trade off requires A deliberate selection between one stakeholders
preferences as well as between different stakeholders preferences. Effective
tradeoff requires understanding value, preference and priority, as well as the
scope of change necessary to realise the target.
Practitioners are most valuable facilitating trade-offs between stakeholders and
across organisational boundaries, allowing different stakeholders to effectively
measure preferences, priorities and costs that they do not intuitively understand.
So it's all about providing them with the options and then it's still very much down
to their decisions.
So again, if you're getting questions about looking at alternatives, looking at
trade-offs, it's not your decision. You know it, it's it. You know, you might make a
decision, but it's got to be a decision based on what the stakeholders want, it's
not just you turning around the same right this. Is what we're. Going to do
without having.
Consulted with the stakeholders first.
 theknowledgeacademy
Of course, in any situation, any trade-offs are you're gonna be those, you know,
perceive themselves to be losing out, whereas others are gaining and that's, you
know, in practical terms, one of the difficulties in in the getting a satisfactory
trade off.
Trade off decisions. Most common interpretations of trade-offs are a banners
achieved between 2 desirable but incompatible features. Some sort of
compromise and losing one quality aspect or amount of something in return for
gaining another quality aspect or.
So we come to the practise with learning studies at stakeholder management.
So we go in here and we look at the stakeholder management, so unit 2. There
are two questions associated with Unit 2. Again, allow yourself 10 minutes for
each question.
What, 10 minutes to do the question and then obviously you can check your
answers and that could take some time.
But you've got there two questions that are associated with Unit 2. And of course
you can, yeah, check your answers in the answer booklet.
 theknowledgeacademy
TOGAF® EA Practitioner Unit 3

In Unit 3, we're going to have a look at phase A, the starting point. It refers to the
extract of the Togaf standard 10th edition. Go and have.
What we'll be looking at would be the part one of the C220 document, which
covers the ABM and the phase of course we'll be looking at phase an architecture
vision and what's involved in that.
So, we'll have a look at the information necessary to execute the architecture
vision phase, how to apply phase A and how it contributes to architecture
development, work security, specific architectural design that's sufficient for
phase eight and output message to proceed with the architecture development.
So, information there say to execute the architecture vision phase. We need to
identify.
Stakeholders concerns and business requirements to find the scope of our
architecture project and evaluate capabilities, identifying stakeholders, concerns,
and business requirements. Explore a repository for superior architecture,
constraints, and guidance, if there is any.
Have a look at the stakeholder map. Be completely clear which stakeholders must
be served and what they are worrying about because it's important that we
understand what the stakeholder concerns are. Then we can define the scope of
the architecture project. What problem are you hoping to solve in terms of the EA
landscape, the breadth and planning horizon and in terms of purpose, which will
tend to confirm the necessary level of detail, be completely clear where in the
business cycle this architecture will be used. And then evaluate capabilities of the
EA team to take a hard look at the EA team and confirm the ability of the team to
deliver on this architecture development project.
A good EA team covers gaps in experience, skill and bias to deliver the
architecture that's useful overcoming weaknesses of some members of the team,
a lot of this would have been done potentially in the preliminary phase if we had
arrived here from the preliminary phase, particularly with regard to looking at
whether we've got the team available but when it comes to phase A, we could
have arrived at phase.
 theknowledgeacademy
A from phase eight as a result of a change request or from the phase effort of
creating our architectural landscape, more information through iteration iterate
through all the domains, performing sufficient architecture development to
enable you to communicate to the key stakeholders, how the problem can be
addressed and what the scope of change is it depends on.
The level of architecture as to how much you need to do of each of the domains,
even if it's just the case of saying well, look, you know we're not really interested
in the data, application architecture or even maybe the technology architecture at
the level we're at, if we're at a strategic level.
For example, the focus would be very much on the business architecture, but as
we go lower down in the landscape, then the other architectures will crucial in
the determining the scope, be clear on the target. The value of the target and the
work to change the outputs of phase A requires exploring all of the domains,
whether the expiration is to understand what should change or where change is
not an option to determine the impact of retaining current architecture. And
there may be multiple potential targets after the initial exploration how to apply
phase a and how it contributes to architecture development work set of
essentials of phase A are to define the scope of the architectural project, identify
the stakeholders concerns and associate requirements, and assess the capability
of the A-Team that we've just been we've just seen and then the completion
essentials key stakeholder agreement on a summary of the target and the work to
reach the target. So there are a number of steps there. These steps don't have to
be done in the order that they are listed here. It's just a suggestion. There are
some activities that you would typically need to do before other activities, but a
lot of the activities could be done in terms of for example.
Publish architectural project and identify the stakeholders, concerns and business
requirements and that's the output of that activity. You could then feed into the
creation of the statement of architectural work.
Look into rather the creation of the communications plan along with the state of
architecture work, which is the last one on the list so you could be doing a bit of
the at the second one and then doing a bit of the last one so you know as with the
you know a lot of the phases it's quite an iterative sort of process in in terms of
the order in which you do the activities, you don't have to do every activity listed
 theknowledgeacademy
here every step and you certainly don't have to do them in in the order you know
start from the 1st and working your way down through the various steps confirm
elaborate business goals, business drivers and constraints.
You may well have done a lot of that again in the preliminary phase, but if you've
arrived here from say, Phase H or Phase F, then there might be a bit more work
involved assess readiness for business transformation. There is a technique called
the business transformation readiness assessment technique, which can be useful
to determine whether it's even worthwhile going forward from where we are at
present because it looks at the softer side of the project, one might say looking at
the more sort of human, the business side define the scope of your architecture
project, because a big output from phase say besides the architecture vision is
going to be a statement of architectural work which says this is what we intend on
doing and a big part of that document would be some sort of architecture project
plan which is sort of what they're you know.
Talking about there with defining the scope. Government elaborate architecture
principles, including business principles. That's if it's appropriate and a lot of the
work we do with principles would have done in the been done in the preliminary
phase. So, it might just be a case of checking and saying Yep, the principles are
still fine. We don't need to do much here or it might be again if we've come from
Phase H or Phase F to get to.
You say it might just be a case of looking and saying, well, OK, as a result of a
change request, this principle may then no longer be valid, or it might be the case
if this principle will then come into play. It just depends on the development of
the architecture vision. The vision is always going to be high level throughout and
as a result, if at some point there is a change and it's going to affect the vision
that the chances are probably looking at being a new architecture project.
Because it's very rare, you can change the vision without actually changing the
overall project, because it is such a high-level document defining the target
architecture, value propositions and KPI's.
It's very much related to the architecture project. Identify the business
transformation, risks and mitigation activities and develop the statement of
architectural work and secure approval statement of architecture work is
something that would be it would be being developed throughout various
 theknowledgeacademy
activities, various steps within phase A and if it gets sort of finalized here before it
gets signed off by the sponsor and because it gets signed off by the sponsor, the
statement of architecture.
Work is often seen as or referred to as an architecture contract, that being a
contract between the sponsor and the architecture team, how to apply the phase,
the level and detail addressed in phase.
I think to be fair, the level of detail in most of the phases is very much dependent
on the scope and goal of the goals of the request for architectural work or the
subset of scope and goals associated with this situation of architectural
development. The order of the steps as well as the time at which they are
formally started and completed, should be adapted to the situation and in
accordance with the established architecture, governance, security, specific
architecture, design that is sufficient for phase A.
In phase A sufficient security specific architecture design should be carried out to
satisfy the security stakeholders that the end to end state does not represent any
unknown or acceptable risk and aligns with corporate policy standards and
principle.
And then satisfy the business stakeholders, in particular those who control the
budget that the security architecture is instrumental in enabling and supporting
the overall architecture required to deliver the business opportunities and
benefits identified with the right balance between risk compliance and business
benefits stakeholder approval.
All stakeholders will have security and risk concerns and associated requirements.
The stakeholder requirements are gathered to determine the security blueprint
needed to address the various concerns the stakeholders might have.
Stakeholders typically have value concerns related to the security architecture.
Value may be measuring items such as reduced risk and enablement of overall
architecture. Viewpoints and business cases must build on security principles,
drivers, risks, key risks and key appetite and should be an integral part of the
overall architecture.
Vision deliverables outputs necessary to proceed with the architecture
development, the approved statement of architecture. What I was saying about
 theknowledgeacademy
the state of architecture work gets signed off by the sponsor at the end of Phase
eight to say yes, we agree to your plan to do some work that you can go off and
do it. Refined statement of the business principles, goals and drivers. Architecture
print pools capability assessment, tailored architecture framework, architecture,
vision, the draught architecture definition document that's very similar to the
vision in both of them in phase A very high level and they contain baseline and
target architectures. The difference is that the vision would remain high level
throughout the various phases, whereas the definition document would become
more defined as its name suggest.
Tests as we go through phases B, C&D and we get more detail for the
architecture’s communications plan. That's a significant output in the
communications plan for your architecture project, and I like the approach that
they've taken with regard to stakeholders identifying stakeholders and
communicating with them in that you end up hopefully with a more structured
process and more engaged process for the stakeholders.
Rather than is often the case where the communications plan is just simply a
document, we say we'll send everything to everybody and eventually gets the
right person, which isn't really a plan or a strategy other than a default, or we
can't really be bothered. So at least they're trying to encourage you to identify
stakeholders.
Classify the stakeholder and then tailor the engagement with those stakeholders,
some of the key deliverables from phase eight, we have the statement of
architecture work that defines the scope and approach that will be used to
complete an architecture development cycle.
So this is very much our architecture project plan, statement architecture work is
typically the document against which successful execution of the architecture.
Project will be met 3rd and may form the basis for a contractual agreement
between the supplier and the consumer of architecture services, IE between us as
the A-Team and the business sponsor architecture. Vision provides a summary of
the changes to the enterprise that will accrue from successful deployment of the
target architecture, purpose of the vision is to provide these stakeholders, with
the formally agreed outcome early agreement on the outcome, enables the
architects to focus on the detail necessary to validate feasibility and providing an
 theknowledgeacademy
architecture vision also supports stakeholder communication by providing a
summary version of the full architecture definition. Vision is always high level
high. The high-level representation of baseline and target architectures,
communication plan or communications plan, enterprise architecture contains
large volumes of complex and interdependent information. Effective
communication of targeted information to the right stakeholders at the right time
is of critical success factor for enterprise architect.
Picture development of a communications plan for architecture allows for the
communication to be carried out within a planned and managed process, and, if
nothing else, it just creates an overall better engagement with the stakeholders.
If you've got a more targeted approach, you know where you're actually looking
at individuals classifying them accordingly and determining what information they
need, rather than just the in some cases the scatter gun approach where you just
go right, let's just send everything to everybody, which is supposedly a plan or be
it that there's not much planning other than just send it all out.
Essentially output stakeholder response that and management want guidance on
planning and executing an effective change not on architecture. What the
enterprise values and consumers is typically different than what the practitioner
produces, practitioners deliver and essentially, I'll put the intent is to keep the
focus on the outcome being pursued not what is done.
That is a summary output and outcome and essential knowledge phase,
architecture, vision output, and outcome. Sufficient documentation to get
permission to proceed permission to proceed to the developer Target
architecture to prove out a summary target an essential knowledge.
The scope of the problem being addressed, those who have interests that are
fundamental to the problem being addressed, so stakeholders and concern and
what summary of answer to the problem is acceptable to the stakeholders in
terms of the vision and stakeholder priority and preference? What value does the
summary answer provide so phase A is all about establishing your architecture
project planning, what you're going to do in response to the request for
architecture work and creating a number of significant outputs, including the
architecture vision, the definition document, as well as the communications plan
if you have the learning studies. Then there are two practise questions associated
 theknowledgeacademy
with Unit 3 so you go to the documentation here and we have a look at Unit 3
phase A. The starting point we have question one and then we have Question 2
so, two questions associated with that particular unit. Again, allow yourself 10
minutes to have a go at answering each question and you can cheque your
answers in the answer PDF for this learning studies.
 theknowledgeacademy
TOGAF® EA Practitioner Unit 4

Unit 4 focuses on the architecture development that's faces primarily phases

BC&D. We'll have a look at Steps applicable to all three phases. It says all the ADM
phases, but it's really talking about all three phases in terms of B C D risk and
security considerations.
During the architecture development, relevant information to produce outputs
valuable to the architectural development. How to employ phases B C&D and
how they contribute to the architecture development information relevant to
Phase C data and application to produce outputs from the architectural
development information needed in Phase D to produce outputs relevant to the
architecture development outputs of VCSH proceed to the architectural
development work, so steps breakable to all three ATM phases. It's not all ADM
phases, as in every ADM phase will have these particular steps, but certainly
phases BC and we will have common steps outlined in the total standard to
develop architecture and phases. BC&D are identical. They're identical because
the approach to developing an architecture confirming the work products develop
fits and confirming approval are identical. The only thing that changes is the
domain that we're.
With these steps are also mandatory. Steps can be skipped, but the final outcome
could be at risk. They are also in a fairly sort of tight sequence of tight order in
comparison to the to the other phases, because a lot of the activities rely on
previous activities having been completed so there's little room for maneuver
when it comes to varying the order of the activities, the order of the steps.
Practitioners test with the following questions. Given a set of stakeholders and
concerns, what information do you need to know about the system being
examined to address their concerns.
Given a set of information, how will you model represent, capture and analyse it?
Are the reference models that allow you to skip to gathering and analysing rather
than inventing, and what information is missing from the EA landscape right now
about the target baseline and gap? So just enough for the purpose. Consider the
limitation of restricting description as to where there is a gap if part of the EA
landscape will have no change and it's not needed for traceability, what useful
 theknowledgeacademy
reason is there for a practitioner to spend time describing it if they've already got
the description and it says the gap is everything that changes. I would say the gap
is anything that changes rather than being everything because there will be lots of
gaps. But there we go. Identify the work to reach the target, considering the costs
and values. Without understanding the work required to reach the target,
stakeholders will approve the impossible. Often the practitioner is accountable
for guarding value. A target provides an increase in value at a cost of change.
The practitioner explores the impact of their candidate architecture against other
candidate architectures, transition states, target state and implementation
projects work with the enterprise risk management process to assess impacts to
the enterprise’s risks. This is one of the most complex activities for an engaged
high functioning be a team approval. The practitioners assisting their
organisations select the best possible path, so we're assisting again. It comes back
to the wording they're using, we're assisting the organisation to select the best
possible path against the set of competing preferences. Over time, they have
taken the time to explore options and impacts with an approved target
architecture, the future is to find traceability to the objective is available and
trade off has been performed.
The EA repository practitioners should start and finish with the contents of the EA
repository. They should apply the following tests.
Is the information that will address the question and already available. Is there a
superior architecture that the guides and constrains the task and what is the
minimum information?
Needed to cover shortfalls in the EA repository, risk and security considerations
during phases BC&D.
Security elements of Phase B comprised business level trust risks and controls.
These were independent from specific it or other systems within the specific
scope of the architecture, engagement, security, elements of Phase C comprised
functional security services and their security classification and security
considerations.
Phase D the architectural risk, technology, architectural risk and security. In most
cases, the development of specific technology, architecture, security artefacts is
 theknowledgeacademy
not necessary as long as it incorporates the relevant security controls and
mechanisms defined in earlier phases, security architect must ensure that the
required controls are included in the technology architecture and verifying
whether the controls are used in an effective and efficient way. Relevant
information to produce outputs valuable to the architecture development and
understanding of these is essential, so understanding the business goals and
principles and drivers to align the architecture work with the business they
provide the context for the architecture work they describe the needs and ways
of looking working with the enterprise relevant information from phase a scope of
the problem being addressed, stakeholders and their concerns, and the summary
answer to the problem that it's acceptable to the stakeholders reference
materials external to the enterprise if there are any non-architectural inputs,
request for architect, Work, business principles, goals and business drivers,
capability assessment and communications plan, architecture development phase
B inputs all of the usual suspects.
We'll see how all of the time with the inputs that the input list is very similar
because it's the same inputs that are being fed into be and then into C and then
into DW to say into and into and into could be that that all of this is being fed into
BCD at the same time.
But going forward, it would be, you know, a similar sort of list on the subsequent
phases, nothing particular.
Well, I say that's particularly the draught architecture definition documents, quite
interested in some respects in that it is just a draught document and remains.
Draught all the way round to Phase F where it gets finalised, but as a document.
It starts out, you know with quite high level in phase A, but then gets more
detailed then Phase B, particularly with the business architecture and then if it
were appropriately, we get updated with the relevant data application
architecture information as you go through the subsequent phases list of the
deliverables is in the handout at an Appendix B.
If we go into about there, those are the outputs from the various phases and
that's the inputs, and there's also a list if we go to appendix. So that's the entities
and then we've got the metamodel attributes and then the relationships and then
 theknowledgeacademy
at Appendix A there, we've got the typical deliverable output, but again that just
gives you a description of the outputs from the tables from the various phases in
terms of the actual descriptions. That's the supposed tape or that it shows you
where the deliverables output from the various phases, but I wouldn't take
everything that's in there as being entirely accurate.
Unfortunately, this has come straight from the toner for standard PDF, so that
would be out of C220 part more, but if you want to actually see the descriptions
of what the various deliverables are about, then you'll find that in the C220 Part 4
PDF how to apply phases BC&D and how they contribute to the architecture
development work outputs of course, or give us a set of domain architectures
approved by the stakeholders for the problem being addressed. A set of gaps and
work to clear the gaps understood by the stakeholders that's the outcome and
outputs sensual knowledge. How does the enterprise current enterprise fail to
meet the preferences of the stakeholders? What this change to enable the
enterprise to meet the preference is what work is necessary to realise the
changes that is consistent with the additional value being created and how
stakeholder priority and preference are just in response to value effort and risk of
change, the order of the steps as per usual can be altered, although there's little
room for manoeuvre when it comes to phases BCD, because there there's all
dependencies between the various steps you often find that you can't do one
particular activity that you've done previous activities because they are very much
based on the activities that require the previous output architecture repository as
part of each phase. The architecture team will need to consider what relevant
architectural resource are available in the repository Phase B business
architecture scope depends on existing strategy and planning. Update and verify if
it needs to be updated bridge between the high level business drivers and
strategy and goals on the one hand and specific business requirement on the
other existing architecture, discovery must include all relevant detail. If there isn't
any existing strategy or planning, obviously you'll need to develop it and that will
take a bit more at work levels of detail will depend on the scope and goals of the
overall architecture effort. New models characterizing the needs of the business.
Need to be defined in detail. Well, the relevant level of detail during Phase B,
existing business artefacts to be carried over and supported in the target
environment may already been adequately defined in previous work.
 theknowledgeacademy
If not, then they will need to be defined as well applying Phase C information
systems architectures phase C.
Remember, isn't there? Isn't actually something that's information systems
architectures per say. It's a combination of the data and application architectures,
and they can be developed in either order advocates exist for both sequences.
It's examples I've I'm a bit mystified as to why there's still persisted with this
speed whack or speed wax enterprise architecture planning recommending a
data-driven sequence. It's like. So, what it doesn't really matter because even if
you do the data first or the application first, you end up where we doing both?
and it's racing between the boats as well. So yeah, I mean, a lot of the time it
comes down to whether you're looking at something bespoke, in which case
there might be a bit more focused on the data, whereas if it's something more
sort of commercial off the shelf, then you tend to accept the data that comes with
the application Phase C information systems architecture, key considerations for
data architecture could include data management, migration and governance,
although they don't go into any detail of what they are, they're just things to
consider applying Phase D technology, architecture, the evolution of new
technologies is a major driver for change in enterprises looking for new,
innovative ways of operating and improving the business technology architecture
needs to capture the transformation opportunities available to the enterprise
through the adoption of new technology.
Information relevant to Phase C or it could just be a case of with the technology
architecture, identifying what technology you know architecture is required to
support the business architecture because this is almost inferring a sort of dry.
Moving the architectural change from the bottom sort of upwards, rather than it
being more sort of top down. If you're looking at business architecture being the
first, yeah, I guess it is a possibility, but a lot of the time it's a case of saying right,
this is the business change. This is the data application needed and then this is the
technology, if any that's needed to support the business change information
relevant to Phase C data and applications to produce outputs for the architectural
development reference materials external to the enterprise non-architectural
inputs request for architectural capability, assessment, communications plan and
in terms of architectural inputs, a very similar list to what was the architectural
 theknowledgeacademy
inputs for Phase B. The only difference is that we've got the draught Architecture
requirement specification document here in Phase C as an input and that wasn't
and then put it into Phase B because it was created in Phase B to act as a
companion document to the architecture definition document.
But it's the same usual suspects, so to speak, when it comes to the input essential
knowledge how does the current enterprise failed to meet the preferences of the
stakeholders? This all sounds very similar, of course, because it is very similar to
what we saw for Phase B.
What has changed to enable the enterprise to meet the preference of the
stakeholders? What work is necessary to realise the changes that's consistent
with the additional value being created and how stakeholder priority and
preference are just in response to value, effort and risk. I mean that that's
something that's again, common across the quite a few of the phases the
information needed in Phase D to produce outputs relevance. The Architecture,
development reference materials external to the enterprise architecture,
reference materials and product information.
On candidate products, non-architectural inputs, requests for architecture work,
capability assessment, communications plan, architectural inputs, the
organisational model for enterprise architecture, including the scope of the
organisations impacted maturity assessment gap and quite why they're suddenly
decided to span these particular inputs, whereas they just listed and previously.
You know it's a bit of a, you know, mystery because you don't particularly need to
know all that detail for phase D. But it's just showing you what's what could be
included in the various input, Architecture principle, technology principles if exist
statement of architect work after it's all the usual suspects. Again, just
highlighting in a little bit more detail certain inputs. So, architecture repository
draught architecture definition.
Document which would have potentially high-level baseline and target
architecture previously. So, this is true for all of the domains and gets updated
where appropriate.
Essential Phase D knowledge how does the current enterprise felt? Well, look,
we've seen all this before it. It's a bit sort of day shop view what must change to
enable the enterprise to meet the preference is what work is necessary to realise
 theknowledgeacademy
the changes we did say previously that phases BC&D are pretty much identical.
You can see it here as well with the slides having very much the same, but what
it's doing is changing the domains that was the phases.
BC and DSA should proceed with the architecture, work refined and updated
versions of the architecture, vision, phase deliverables to update it as
appropriate. There are lists of the outputs for each phase included in the
handout, and so that was the going back up here, we had the list of the outputs
from the various phases. So, if we go back up to and that's the that's model stuff.
So, architecture development outputs, so list of all the outputs from various
phases and we can see there.
I mean, that's here in the handout, but if you go into the C220, part one
document which is the Adm. Then of course you can see the outputs for each of
the phases, they've just put them together.
You know, in one big list there and the hand down, but you could you could
equally go and see them there in terms of the that the outputs of each of the
phases, but they're all very similar sort of outputs as you would probably expect
outcome and output centre domain architectures approved by the stakeholders
for the problem being addressed, set of gaps and work to clear the gaps
understood by the stakeholders. If you have the learning studies then there are
two practice questions related to this particular unit to architecture development
for phase for Unit 4 here and we have a look at the Unit 4 there, which is on page
18 of the learning studies. You can see there, we've got Unit 4, question one for
architecture development and then we've got question two. So, we've got two
questions associated with Unit 4, sorry. Three questions associated with Unit 4 for
the architecture development.
So, give those a go again 10 minutes per question and then obviously checking
your answers in the answer booklet.
 theknowledgeacademy
TOGAF® EA Practitioner Unit 5
Unit 5 looks at implementing the architecture and it's as its name suggests, it's
very much looking at phases E&F&G and because it's talking about implementing
the architecture that's going to be activities done by our planning framework, our
implementation team, the search.
We as an architecture team or as an architecture capability will be involved with
phases EF&G, but more in an oversight position than necessary. Doing a lot of the
work because, as we shall see, it's all about identifying solutions.
Choosing solution and then planning the implementation of the solution and then
in Phase G actually doing the implementation of the solution.
So we'll have a look at risk and security considerations for phases EF and G steps
phase E to create the implementation of migration strategy. Basic approaches to
implementation.
Identifying grouping work packages, creating a documenting transition
architecture. The impact of migration projects on the organization and
coordination required.
Why and how business value is assigned to each work package? How to prioritize
migration projects? Confirm the architecture road map which is in Phase F?
That was the Phase F and SH. Proceed with the architectural implementation
inputs into Phase G the implementation governance, how implementation
governance is executed, which is Phase G outputs to support architecture
governments and how architecture contracts used to communicate with the
implementors. So, we start by thinking about the risk and security considerations
for phase ZF&G.
Looking at Phase C to start with, ensure the stakeholder security and risk concerns
were addressed in the analysis for further risk, owners are consulted, the value
expected to be delivered by work packages should include measures related to
security and risk value to ensure the road map addresses the complete set of
business goals and drivers.
 theknowledgeacademy
Security building blocks defined in the previous phase has become solution
building blocks in this phase so that more specific implementation-oriented
requirements and specifications are defined and the security services catalogue of
the baseline security architecture will probably contain existing security services
or security.
Building blocks that meet the requirements phase F migration planning. The
migration strategies you include a risk assessment and a risk mitigation plan. In
phase of the risk mitigation plan is limited to the trend.
Session migration of live environments should always include regression planning,
so there is a way to reverse out of a failed migration. Central part of risk
management so.
Whatever it goes all goes wrong. Can we mind it back?
In addition, migration planning should include security impact analysis to
understand any security impacts of the target state of the chain.
And then Phase G implementation, governance, security, architecture,
implementation, governance provides assurance that the detailed design and
implemented processes and systems adhere to the overall security architecture.
This ensures that deviations from the architectural principles and implementation
guidelines don't create any unacceptable risk steps phase to create the
implementation and migration strategy.
There are a number of steps. Again, as with previous phases, you don't have to do
the steps in the order that they're laying out here. In fact, there is a natural
iteration that takes place between certain steps within the phase.
Determine the and confirm the key corporate change attributes. Determine the
business constraints for implementation review and consolidate gap analysis
results from phases B to D there's a lot of consolidating and reviewing going on in
in Phase C, particularly with regard to gap analysis, because we would have been
doing the gap analysis in BCD and that's why it's talking about consolidated
results, so that we have a more joined up picture of what the gaps are and how
they relate to each other.
 theknowledgeacademy
Review the consolidated requirements across related business functions,
consolidate and reconcile interoperability requirements. So there's a bit of
consolidation and reviewing going on there for both.
The requirements and the interoperability, refine and validate dependencies.
There are a number of techniques that they talk about in phase and Phase F
which potentially you could determine the sequence of implementation, but from
experience it's things like dependencies which tend to sort of rule the roost
because you have often had to do things in a certain order.
There's very little room for maneuver at times in terms of or we must do this
because we've got this dependency confirm the readiness and risk for business
transformation, formulate implementation migration strategy, identifying group
mature work packages, identify transition architectures and create the
architecture road map and implementation and migration plan.
The big output of phase C is the two big outputs, the road map and the
implementation migration plan in terms of the order in which we do the activities,
it is very sort of iterative overall as a phase and when you go through certain
activities, you'll think well, hang on a minute.
I've already been doing some of this before, or it would actually make more sense
too.
Do it in a order the identifying the transition architectures starts in phase and
continues into Phase F and in in some respects it's easier to look at Phase ZF
collectively because there is a big, typically a big overlap between phases E&F in
terms of activity.
Is in the case if you must do all the phase before, you can do any Phase F it's very
much doing them in in parallel.
The architecture road map and the implementation of migration plan at this point
would typically be seen as sort of draught versions and then the finalised.
Versions of both would be created and on with pretty much the finalised versions
of everything else that might have been drafted up until now, that's they get
finalised, versions created in Phase F, basic approaches to implementation and
there are three basic approaches as follows. Greenfield, completely new
 theknowledgeacademy
implementation that doesn't in my experience happen that often revolutionary
and radical change I switch on switch off. That also doesn't get carried out that
often because there's a lot of organisations out there that would have the
capacity to do that, let alone the inclination, a more likely approach is the third
one, which is the evolutionary that's your face implementation. Your transition
architectures parallel, running your systems and so on. So of those that's the
more common as the approach is the evolutionary.
Revolutionary, by the way, doesn't mean that it's something radically different. It
just means that you, you.
Did it in one step rather than doing it incrementally with transition architectures
and that's your evolutionary approach. Implementation approaches the most
common implementation. Methodologies are quick wins snapshots.
This can quite as often come as a surprise to people because they think, well,
totally off an enterprise architecture is supposed to be strategic.
Yeah, they're talking here about quick wins. What's going on? Well, that's because
of the fact that within the context of a strategic approach, you can still look where
possible to get quick wins and quick wins is primarily there to deal with
stakeholders and making sure the stakeholders are happy with you.
You Know in some cases before they commit to full funding for a project, or it just
might be a case of making them aware of what the possibilities are and then they
might you know they might be looking at sort of you know seeing some value
from the early part of a of a major sort of transformation. But that's only if it's
possible. Sometimes you know you just have to do things in a certain order and
quick wins, then you know may not apply, but quick wins is a possibility
achievable targets? That's much more of your sort of strategic approach and
value chain method never actually seen anybody using this particular
methodology in terms of using it to determine the sequence implementation
anyway.
But it's something that is originally it used to say value chain method, EG the Nas
CIO methodology cause the North America state chief Information Officers group.
Use the value chaining method.
 theknowledgeacademy
You don't need to know particularly about value chain method, but it's just.
A possible implementation methodology. The two most common of the first two
of the quick wins and the achievable targets, so that's much more strategic
approach.
Identifying and grouping work packages use the consolidated absolution
dependencies matrix, together with the implementation factor assessment and
matrix.
To logically group the various activities into work packages, we'll pick up on what
the consolidated gap solutions and dependencies matrix and the implementation
factor catalogue all about a little bit later on.
I think it's in Unit 8 when we cover some of the techniques, including the
migration planning techniques, it's filling the solution column in the consolidated
gap solutions and dependencies matrix recommend the proposed solutions
solution mechanisms and indicate for every CAP and activity whether the solution
should be oriented towards a new development or based on an existing product.
And or use a solution that can be purchased classify every current system that is
under consideration as mainstream, contained or replaced more terminologies if
we really needed it mainstream systems and systems that we've got, we're gonna
keep their part of the target contained systems.They're ones that we're gonna
keep for now.
That they will be removed before the end of the overall transformation and
replace systems. They're going to be replaced within the current phase .
So really, it's a case of keep for now, replace now or the middle. Yeah, the middle
one keep for now, but replaced later as well.
I've never seen anything.
Other than these slides to do with the mainstream container replace certainly
that's never really featured.
As far as certification questions are concerned supporting top level work packages
should then be turned in turn, decomposed into increments to deliver the
capability increments as required.
 theknowledgeacademy
Analyse and refine the work packages or influence with respect to their business
transformation issues and the strategic implementation approach, and finally
group the work packages into portfolios and projects within the portfolio, taking
into consideration the dependencies and the strategic implementation approach.
Creating and documenting transition architecture.
Transition architecture applicable when the scope of change to implement the
targeting architecture requires an incremental approach.
Which in I would say the majority of cases is the case, identifies one or more clear
targets on the road map to realising the target architecture, development of
transition architectures must be based upon the preferred implementation
approach. The consolidated Gap Solutions dependencies matrix, the listing of
projects and portfolios, as well as the enterprises.
Passage of creating and absorbing chains of how much change can they can they
deal with at anyone time?
Determine where the difficult activities are and unless there are compelling
reasons, implement them after other activities that most easily deliver missing
capability.
So again, trying to sort of put it into some sort of order, but that's assuming that
you, you know you don't have dependencies because they will play a big part
when it comes to determining the sequence of implementation transition
architectures can be useful, but you just have to be mindful of the fact that when
you get to a point where you're not where you were at the start, so you're not at
the baseline, but you also haven't yet reached reached the target.
There can sometimes be major challenges with regard to interoperability in those
sort of transient or transitional states.
Where once you've got everybody on the target, then then a lot of that
disappears, but it might be that there's this sort of, you know, in the middle
ground where you know some of the implementation has taken place and it
hasn't really been thought through in terms of how the output from the new
system is going to integrate with the outputs from the previous systems, if they're
gonna integrate at all. So yes, transition architectures are useful. We just have to
 theknowledgeacademy
be mindful of the possibilities when it comes to dealing with the transition
architectures.
Impact of migration projects on the organisation and coordination required Phase
F migration planning confirm the management framework interactions for the
implementation migration plan. The sign of business value to each work package.
Estimate the resource requirements project time is availability and delivery
vehicle confirmed the architecture road map and update the architecture
definition document. Complete the implementation and migration plan and
complete the architecture development cycle and document lessons learned. A
number of these activities in the phase therefore would have been typically being
carried out along with the activities from phase three because there's quite a few
activities in Phase F which are related to planning and the initial planning took
place in phase eight and therefore a lot of these activities would have come into
play with in the background of any of the planning.
Phase set implementation and migration plan output and outcome as approved
set of projects containing the objectives and any necessary constraints, resource
resources required and start and finish dates. Essential knowledge resources
available to undertake the change. How stakeholder priority and preference
adjusting response to the value, effort and risk of change standard stuff there.
So it's walked through architectures to support project finalise scope and budget.
So for each project in the portfolio, finalise the estimates and timeline and update
the road map and populate governance and approval plan.
To support solution delivery, look at the programme context, initiate completion
of the architecture work, define the target solution architectures, finalise the
effort and resource estimates to find the variance measures and update the risk
matrix as is appropriate, realising the solution contractually, this is the post
rollout warranty period.
It's the period of putting the solution in the hands of the beneficiaries, customers
and user support personnel, etcetera. At the end of this period initiated gap
analysis between the realised architecture and the baseline to be used for
solution delivery. Document the lessons learned, mainly the gaps in the
description of the superior architecture that were filmed while delivering the
solution architecture closure the realised solution is the new baseline and
 theknowledgeacademy
becomes the basis for evolving and analysing the road map to the target
architecture. The architecture practitioner performs an assessment to justify
closure of the current architecture project and evolve all stakeholders, decision
makers and implementers to complete the assessment and then gain the sign off
to close the effort. Why and how business value is assigned to each work package.
This is a migration planning technique that you could use to potentially determine
the sequence of implementation, establish what constitutes business value within
the organisation, and how the value can be measured, and then apply this to each
one of the projects and project increments. Use the work packages as a basis of
identifying projects that will be in the implementation migration.
Plan the identified projects will be fully developed in other steps in Phase F, which
should then be assigned to the projects and project increments by negating the
risk identified in the consolidated gap solution dependency matrix.
And estimate the business value for each project against the business value
assessment technique and the business value assessment technique, it's alright as
the technique goes, it could have been a little bit better if they'd have looked to
put a bit more sort of information and that might sound contradictory to the fact
that it's quite get you know, potentially gets quite cluttered, but very much
looking at the projects that will be fully developed in other steps in Phase F.
And then the risks for the projects are aggregated, the business value assessment
technique involves drawing up a grid with risk along one access and value on the
other access, and then plotting the relevant projects. And from using that
information to determine what the actual sequence of implementation is going to
be well I say determine have an impact on it because there are other factors that
will also potentially have an impact on the sequence of implementation issues to
address in the activity the business value. So what's the value of the relative
relative value of the project and potentially using that to determine which order
that we're going to implement the projects in communication with implementers,
implementers need to understand their project.
Where the project fits in with the road map and its role in producing value, what
work packages and gaps they're responsible for, as well as associated gaps that
they're not responsible for, and how performance will be assessed so part of the
communication with the implementers will be to tell them, oh, by the way, this is
 theknowledgeacademy
when we're going to go and cheque to make sure that features A&B are being
delivered and that they meet these specifications, and then we've got another
couple of features that will cheque up on in a week's time to see whether that's
been implemented or whatever the appropriate time frames are, but we would
have documented that as part of giving out a contract to not directly to the
implementers in terms of us as an architecture team, given the implementers, but
we would get have established something with the planning framework typically
and then they would be the ones that are directly liaising and contracting with the
implementers, particularly if they're a third party managing the current approach
towards implementing the changes.
Practise this job is to show that a sufficient level of scrutiny led to the deliverables
of the architecture project for the solution delivery architecture to succeed
proved to the stakeholders that when the architecture project is consumed by the
solution delivery architecture. Their requirements have been met and changes to
the enterprise will be guided and constrained efficiently and identify and secure
approval for the resources necessary to begin allocating the budget for the
solution delivery architecture. To begin, how to prioritise the migration projects in
phase.
Prioritise the projects by ascertaining their business value against the cost of
delivering them. The approach is to 1st determine as clearly as possible the net
benefit of all the solution building blocks delivered by the projects, and then
verify the risks of being effectively mitigated and factored in review the risks to
ensure that the risk for the project deliverables have been mitigated as much as
possible. Project this is then updated with risk related comments how the
stakeholders agree upon a prioritisation of the projects and formally review the
risk assessment and revise it as necessary, ensuring that there is a full
understanding of the residual risk associated.
So this is just another technique and you can go and look at it in terms of
prioritising the project, but if there's dependencies in terms of you've got to do
this activity first.
And then, you know, you may not have any choice, but other than to do that,
confirm the architecture road map, update the architecture road map including
any transition architectures, review the work to date to assess what the time
 theknowledgeacademy
spans between transition architectures should be taking into consideration the
increments and in business value and capability and other factors. Once the
capability increments have been finalised, consolidate the deliverables by project
and that will result in a revised architecture road map update. The architecture
definition document. If the implementation approach has shifted as often is the
case.
Then you need to reflect that in your architecture definition document, because
that up until now would have had just baseline and target architectures, and it
will now include the transition architectures as well.
It says this may include assigning project deliverables and aligning projects and
their deliverables with the transitional architectures to create or update an
architecture definition increments.
Table the architecture definition increments table is something that would
typically be created by your planning framework is as much more of a planning
framework output, and it illustrates the major projects that form the overall
transformation and then using the outputs from the projects potentially
determine the location of the transition architectures, so it's defining the
incremental sort of points, and it's often very much tied in with the outputs from
the various projects.
Outputs the phase FSH to proceed with the architecture implementation of
migration plan approved including the implementation migration strategy, the
project portfolio breakdown of the implementation project charters that's
optional, related work packages, business value, risk issues, options and so on and
approved set of projects in containing the objectives and then this is very
constraints, resources required and start and finish dates inputs into Phase G
implementation, governance, non architectural inputs, request for architectural
work and capability assessment.
And then your architectural inputs could include this I'm still baffled as to why
they've got the request for architectural work identified during phase Z&F.
As an input into Phase G I'm saying bemused because it was previously an input in
previous versions, so we said a long time ago. Well, hang on a minute, this doesn't
make sense, you know.
 theknowledgeacademy
Your request for architectural work wouldn't have, you know, wouldn't have been
created, you know, or identified during Phase E particularly, and if you had any
requests for architecture from Phase F because you're going back round to phase
A, that wouldn't apply here. That would be something that you'd be using in
phase eight to kick off phase eight not to go into to Phase G, so quite what they
were about there. Who knows? But otherwise not too bad a list of inputs and the
architecture contracts standard you can sort of argue as to whether that's just
standardising it's like a template or whatever. It's not the actual sort of finalised
version because the architecture contract gets created in Phase G or be it that it
could be established on information that came from the Phase F, but it's not
created in Phase F.
Even though it's listed here as an input, which would suggest otherwise. It's very
much seen as being created here in phase two. How implementation governance
is executed and confirmed the scope and priorities.
The deployment with development management and identify the employment
resources and skills those first couple of steps very much aligned to the idea of
having some form of gap analysis in in terms of looking at the gap between the
specification and the proposed solution, particularly if there's been a certain
amount of low level design taking place at the start of the phase, which might
then mean that.
What's going to be implemented is going to be very different from the original
specification and as a result of the low level design, there could be new requests
for or request for change, particularly if the specifications no longer match up to
what they intend on implementing the guide.
Development of the solution is deployment that's see at the rather sort of cryptic
way of talking about giving out the architecture contract.
So the architecture contract will get given out in Phase G will get established in
Phase G and that will be a contract between us and our planning framework, they
in turn will have their own sort of contracts with those actually doing the
implementation because we don't get directly involved with that.
And so the architecture contract that's not mentioned but is part of guide the
development of the solutions deploy that would typically be between us and
 theknowledgeacademy
our own planning framework before enterprise architecture compliance review.
So once we've got the contract established and the implementation is underway,
we as an architecture team will then come along and carry out compliance
reviews at agreed intervals throughout the implementation.
And at the end of all of the implementation aspect of Phase G, there may be some
sort of transition into to business as usual, obviously depending and as part of
that, that's where you get your solutions deployed. So implement the business
and IT operations and that's that transition to AU.
What was the target architectures become the new baselines we need to make
sure that the appropriate information, appropriate documentation is updated to
reflect that updating the information stores as is necessary and then perform post
implementation review and close the implementation. That's after everything's
been done in terms of the deployment and that will feed forward into Phase H for
governance purposes.
Outputs and outcomes and essential knowledge for Phase G output and outcome
and completion of the projects to implement the changes necessary.
So it says the completion of the project. That could mean that phase three could
take months, if not years to complete depending on the scope of the project.
Essential knowledge, purpose and constraints on the implementation.
Team Architecture Requirement Specification, House stakeholder, priority and
preference adjust in response to success value, effort and risk for change
supporting change the support of the change activity needs to be provided.
Stakeholders often have little confidence that the project will deliver the
expected value with the expected cost and the projected time. Lack of confidence
means the architecture has more uncertainty or risk associated.
We've realised that the organisations object and at this point, the focus should be
on risk mitigation phase G implementation, governance guidance has provided to
the implementation.
Project practitioner must focus on the scope of the implementation project,
facilitate good decision making in the context, not of project benefits realisation,
but of enterprise benefits.
 theknowledgeacademy
Realisation and ensure the stakeholders and implementers understand the
implications of their choices regarding enterprise benefits, not driving them to
make different choices, implementation projects and other change, Tobias
Standard provides 2 key concepts to go and implementation projects and other
change the architecture contract and the architectural requirement specification.
The architecture contracts used to direct and control the implementation team.
To work towards a thought out future, the architecture requirement
specifications used to directly control the creativity of the implementation team.
And that's again that sort of idea of providing the hand rails when it comes to the
ad trial implementation to support architecture governance, the architecture
contract signed as recommended in the architecture compliant implemented
architectures compliance assessments change.
Requests and architecture compliance solutions deployed so the big E in terms of
outputs from Phase G is your deployed solution, whether it be ELP, GHD or
whatever and or the attendant documentation. So Phase G could take as I say
months if not years to complete depending on the scope of the project summary
of Phase G completion of the projects to implement the changes necessary to
reach the adjusted target state.
Our architecture contracts are used to communicate with
implementer.Implementers are typically poorly served. It's common to see
implementers handed a set of diagrams that represent the architecture from
these diagrams.
The implementers are expected to figure out what the gaps should they should fill
the architecture specifications, things conform to, and the controls they must
implement. Implementers are better served when they are explicitly.
Provided context GAP architecture specification and control critical items to an
implementer. The implementation project context. Where does the project fit
within the road map? What value or value dependency will the project provide?
Scope, what work packages and gaps is the implementation project responsible
for, as well as what gaps associated with any architectural components and
what's the set of specification, specific architecture specifications and controls.
 theknowledgeacademy
The implementation project will be assessed against, so it's important when we
establish the contract when we establish.
What's going to take place in phase three in terms of implementation that we also
get agreement on when we're gonna carry out conformance reviews and what
we're gonna be checking against in terms of the specification.
So they're very well aware of what they're supposed to be producing and what
the measures are further on communicating with implementers John Carver's
policy governance approach has two imperative practises that are recommended.
First, specifications should be exclusionary, highlighting what's prohibited rather
than mandating what is permitted.
And 2nd specification compliance should be assessed through a reasonable
interpretation test point. A reasonable person contract between the architecting
function and the business stakeholders.
Business stakeholders architecture contract may include some or all of the
content that we've got there. Introduction and background nature of the
agreement, Strategic requirements, architecture deliverables. Contract is also
used to manage changes to the enterprise architecture in phase.
If you have the learning studies, then you can go and have a go at some questions
related to Unit 5. There are three questions that we can quickly go to the learning
studies there we've got unified question one and of course we've got question
two and question three. So the three questions in total related to Unit 5, again
give yourself 10 minutes per question and then cheque your answers.
 theknowledgeacademy
TOGAF® EA Practitioner Unit 6
Unit 6 looks at Phase H architecture change management. Although Phase H is
really architecture governance including change management, the change
management is an important part of the governance. But as a phase It's more
typically sat in the background of all the other phases, providing a common
governance across the architecture project. It looks at the inputs Triggering
change management so change request activity is necessary for effective change
management and outputs relevant to proceed with a change inputs triggering
change management change requests to inputs to change management to non-
architectural inputs. The request for architecture Work in terms of architectural
inputs, there are the usual suspects, so to speak, in terms of the puts that we've
seen in previous phases together with change requests which could be technology
changes or business changes or come from lessons learned. One input that I
would add To the architecture and I would add to that list would be the actual
lessons learned themselves, because although it says change requests from
lessons learned, lessons learned and input as well, that could be lessons that we
learned from Phase G, from the implementation or from Phase F from our
architectural work.
Inputs triggering change management phase eight requires the practice to
identify bottom-up drivers for change due to improvements in available
technologies or conditions controlling the operations or environment of the
enterprise, then initiate the architectural work for the next target transition state
change requests during implementation of an architecture, it's possible that the
original architecture definition and requirements are not suitable or not sufficient
to complete the implementation of a solution. In such cases as necessary for
implementation projects to either deviate from the suggested architectural
approach or to request scope extensions. In addition, external factors such as
market factors, changes in business strategy and new technology opportunities
may open up opportunities to extend and refine the architecture activities there
so for effective Change management established value realisation.
 theknowledgeacademy
Established value realisation is the idea of advertising to the wider corporate that
some new or updated capabilities, but we've put in place. And if you think you
can take advantage of It come and Have a word with us if, if, and we'll see what
we can do. So, it's a bit sort of. Although it doesn't sound like it, it's very much
related to sort of advertising, you know in some respects that let the rest of the
organisation know that we've got this new or improved capability. Deploying
monitoring tools is very much about making the EA capability more proactive than
just being reactive, so monitoring everything in anything, managing risks, that's
very much a background ongoing activity within the phase, but also then within
you know your architectural projects provide analysis for architecture change
management.
That's dealing with a change request and deciding what to do as a result of that,
developing the change requirements to meet the performance targets, manage
the governance process. They're very much related to making decisions on
changes and then activate the process to implement change and the change
doesn't have to mean that we have to go and start another project that it could
be that it could be a simple change, maybe a change in the specification which
could result in just literally doing that change the specification and then turn
right. Get on with it or it could be a change that might necessitate you know,
revisiting a phase or a couple of phases, is it or it could be a change request which
says hang on a minute as a result of this, we better go back around and start All
over again and that would have a new request for architecture work to take us
back around to phase A. So, it depends on the severity of the changes to what
needs to be done.
Effective change management matches the change decisions with the business
cycle allocating the resource is identify the bottom of drivers for change? Define
just enough architecture and characteristics of the A landscape and align the A-
Team with the organisation’s planning and budgeting operational and change
processes. So of course, you know change Requests that come in as you know, an
architecture project is not going to be in isolation. So, we need to look at the
impact that it will have on the business as well outputs relevant to proceed with
the change architecture updates, if that's appropriate, changes the architecture,
framework and principles. New request for architecture work to move to another
cycle, so if the changes are really bigger, then we need to go back around to the
 theknowledgeacademy
phase. Right again, the statement of architecture work updated. Necessary
architecture, contract updated and necessary and compliance assessments
updated if necessary as well again, it obviously depends on the change request,
the scope of the changes to what needs to be updated.
Phase H architecture change management summary outcome direction to
proceed and start developing a target architecture that addresses perceived real
or anticipated shortfalls in the enterprise relative to the state or preferences so
very much about making you know, decisions on change requests that might have
come about But it's also providing the common governance process that's sitting
there in the background and part of the responsibilities of the architecture board,
who would typically be sitting in phase eight, would be to cheque to make sure
that we and architecture team are fulfilling our roles correctly so that all going
governance process practise with the learning studies architecture, change
management. So again, into the learning studies document this time.
A couple of questions related to Unit 6. So standard 10 minutes per question.
Well, 10 minutes to do the question. Obviously, it will take longer. To check the
answers are in the corresponding learning studies answer booklet.
 theknowledgeacademy
TOGAF® EA Practitioner Unit 7
In unit 7, we’re going to have a look at the requirements management phase.
Look at the inputs that feed the requirements management phase, how the
requirements management steps correspond to the ADM phases, and the
purpose of the outputs of requirements management inputs that feed the
requirements management phase for guys management, as its name suggests, is
all about managing the requirements the gathering, the requirements, the
identifying of the requirements or prioritising of the requirements, the disposal of
the requirements that all occurs within the relevant ADM phases, and all the
really doing in requirements management is storing the requirements then
forwarding them to the relevant to ADM phases the commerce management
inputs. This is the overall sort of requirement management populated
architecture, repository, organisational model for enterprise architecture, tailor
architecture, framework, statement, architectural work, architecture, vision, all
the standard inputs to the phases that we've seen previously and of course, the
requirements related. Yeah, the architecture requirements populating and
architecture requirements specification. That's the two at the bottom there the
requirements impact, assess and there's the key requirements, related inputs,
effective requirements management is dependent upon clear traceability from
the organisations vision, mission, business model and the strategies through the
most detailed statement of requirement when engaging with stakeholders,
practitioners must maintain the complete set of every stakeholders preference
and the implications of those preferences. So again, it's related to gathering what
the stakeholders want so that we can make informed decisions on their behalf.
How the requires management steps correspond to the ADM phase steps for
objectives and requirements management phase, ensure the requirements
management process is sustained and operates for all relevant ADM phases.

Manage your architecture requirements identified during any execution of the

ADM cycle or phase, and ensure that the relevant architecture requirements are
 theknowledgeacademy
available for. Use by each phase as the phase is executed and then the steps are
matched to each ADM phase and if we go and have a look in the handout, we can
see there that the first step in the ADM phase is to identify the requirements,
typically by analysing how business goals objectives can be met through the
design of value.
Streams business scenarios, user experiences or the provision of management
information, and then document them in the architecture requirements
specification and in the requirements repository and then in the requirements
management established baseline requirements, determine the priorities
confirmed stakeholder agreement to the priorities and document them in the
architecture, requirement, specification and repository.
Moments of the baseline requirements and then in the ADM phase, identify the
new and change requirements. Remove or reassess priority. These have
requirements from reassess modify the existing requirements and then the
requirements management which is on the left-hand side, identify the change
requirements, record the priorities so it's all about. You know, it says identify the
change requirements. It's not really identifying them per say it. It's more a case of,
you know, recording the fact that they've changed. They were actually identified
and changed in the ADM phase and then when it's talking about identifying them,
it's more a case of sort of noting them down change requirements from coming
through any route to ensure that requirements are properly assessed and utilise.
This process needs to direct the ADM phases and record the decisions related to
the requirements, so again it's not creating the requirements or you know when it
talks about, you know recording them or identifying them. It's really just saying,
we've identified that there is a new requirement rather than identifying the actual
requirement itself, It's a subtlety. If you like the requirements management page
need to determine the stakeholder satisfaction with the decisions and where
there is dissatisfaction. The phase remains accountable to ensure the resolution
of the issues and determine the next steps.

Assess in the actual ADM phase, assess the impact of change requirements on
current active phase. Assess the impact of change requirements from previous
phases determine whether to implement change or defer to Nate Radium cycles
 theknowledgeacademy
issue requirements impact statement and then implement the requirements
arising from Phase H or as a result of a decision from Phase H, because the
requirements impact assessment would be set into Phase H and they would agree
and Phase H on not to the changes and then they get recorded in the repository.
So the records management itself is just really about, you know, updating the
information, making sure the relevant information is available and if you look at
what's going on in terms of requirements in the actual phases? Assess or revise
gap analysis for past phases, so it's all about working out the requirements in the
ADM phases and then requirements management is just that just managing the
requirements in some centralised repository within the overall architecture
repository and the idea of having a centralised repository requirements is so that
if you're working on a particular project and it's working in an area that say
another project's working in it means that you can cheque the repository to see
whether there's there is another project dealing with the same requirements that
you might be dealing with sort of avoiding duplication, but in order for that to
work in practise you need to have some standardised template for your
requirements, because otherwise it can be very difficult if you're looking at
requirements of the project and they haven't been made any consistent way. It
can be sometimes extremely difficult to actually work out that it's dealing with
the same or similar requirements.

The purpose of the outputs the requirements, management requirements, impact

assessment and an updated architecture requirements, specification
requirements, impact assessment is what would get sent to the Governance
Board, the Architecture Board in phase eight so that they can make an informed
decision if there is a change request that comes in and they've been asked to
carry out an assessment of the impact of that change on the requirements and
the updated requirement specification if necessary.
Again, just making sure that the right information is available to the relevant ADM
phases, so the requirement impact assessment per person throughout the ADM
new information is collected relating to an architecture, new facts may come to
light that invalidate existing aspects of the architecture requirements. Impact
assessment assesses the current architecture requirements and specification to
 theknowledgeacademy
identify changes that should be made and the implications of those changes. The
Architecture Requirement specification provides a set of quantitative statements
that outline what the implementation project must do in order to comply with the
architecture. Will typically form a major component of an implementation
contract or contract for more detailed architecture definition. So when we're in
Phase G and the implementation is taking place, it would be the requirement
specification or the architecture requirement specification against which the
implementation would be measured.
Certainly from an architectural perspective, while this management process,
when new requirements are raised or existing ones are changed or requirements
impact statements generated which identifies the phase or phases of the ADM
that needs to be revisited, the statement goes through various situations. And so
the final version which includes the full implications and requirements on the
architecture development, once requirements for the current ADM cycle have
been finalised than the architectural requirement specification should be
updated. There is one question related to Unit 7 in the learning studies.
If we go into here and we go to the learning study, so we have Unit 7 question
one. So again, 10 minutes to have a go at that, bring the answers and the
explanations from the answers are in the learning studies. Answer booklet
answers PDF.
 theknowledgeacademy
TOGAF® EA Practitioner Unit 8
Unit 8 looks at supporting the ADM, work has got quite a diverse content, as we
shall see, starting with how the open group TOGAF library can be used to support
the practitioners work business scenarios.
The purpose of compliance assessments and migration planning techniques are
used to review and consolidate the GAP analysis results from earlier phases.
Our repository can be structured using the term architectural repository as an
example of what to expect in a well-run architectural repository, how and the
concepts of architecture levels are used to organise the architectural landscape.
Different levels of architecture exist in an organisation. Determining the level that
architecture is being developed at the role of architecture, building blocks,
guidelines and techniques for business architecture, applying gap analysis.
How iteration can be used in architecture practises? How the implementation
factor catalogue can be used? Content framework and enterprise metal?
Model when the architecture content framework needs to be filled during the
Adm cycles using an enterprise letter model using a taxonomy and how risk
assessment can be used.
So starting with how the open group TOGAF library can be used to support the
practitioners work Tobias Library Company in the standard.
For additional resources contained in the TOGAF library, whereas the TOGAF
series guides are proven stable best practises, the TOGAF library also provides
emerging ideas, guidelines, templates, patterns, and other forms of referential
material to accelerate the creation of new architectures for the enterprise.
So over and above the total standard, which is made-up of the Togo fundamental
content and the series guides, we've got additional guides and reference
materials and overall that's the TOGAF library.
Business scenarios, and techniques to help identify and understand the business
requirements that an architecture must address. The business-oriented technique
used to be part of the total standard PDF it got removed in TOGAF 9.2 and put out
 theknowledgeacademy
into the library in a series guide, which is where it now resides and that's the
G176 business scenarios as a technique. It's similar in a lot of respects too.
Use case technique and in fact, That's probably one of the reasons why people
didn't use it and why it got removed from the TOGAF standard in 9.2 when they
were restructuring they were looking at content largely that people weren't using.
Thing and they weren't using the business scenarios not because it were a bad
technique, but because most of the people at the time looked at it went well.
We've already got something very similar to that, but if you haven't got a
technique for gathering business requirements then you could use the business
scenarios technique. The method to identify the document and rank the problem
that's driving the scenario document.
That's high-level architecture models for business and technical environments
where the problem situation is occurring.
Identifying document design objectives. The results for handling the problem
successfully ensure the objectives are smart, and identify the human actors, the
participants and their place in the business model.
Then by the computer actors the computing elements and their place in the
technology model and cheque for fitness.
For this purpose and we'll find only if necessary. Creating a business scenario.
First of all, identify the problem, the pain points, barriers, issues, the
environment, and the business.
Technology value streams the outcomes, making sure they're smart, specific,
measurable, actionable, realistic, and time-bound. Look at the human acts and
the computing Actors as well.
So formulate A premise, gather the information, and then the initial verification
phase plan. Other information analysed process and then refinement, which again
uses a similar.
Process. If you're interested in the business scenarios as a technique. As I say, go
and have a look at G1.
 theknowledgeacademy
Six purposes of compliance assessments, and best practise compliance
assessments are tightly linked with the concept of an architectural contract. Only
Phase G identifies 2 areas where compliance is assessed. The 1st is the scope of
the project and the 2nd is the actual implementation.
Whether designed or the performance change.
Phase H contains further value-based compliance assessments and then Phase H,
The Architecture Board that sits in Phase H effectively can carry or compliance
reviews at any point in an architectural project. Cheque in on the architecture
team to make sure that the team are working in a compliant manner in Phase G.
The architecture team for a particular project would check to make sure that the
implementation is meeting the specifications.
Its goals of compliance assessments catching errors in the project architecture
early and thereby reducing the cost and risk of changes required later in the life
cycle, ensuring the application of best practises to architecture work, providing an
overview of the compliance for architecture to mandated enterprise standards,
communicating management status of the project.
And there are other purposes or benefits of compliance assessments and
migration planning techniques are used to review and consolidate the gap
analysis results from earlier phases. Migration planning techniques used primarily
in phases ENF.
Hence the name migration planning. We've got an implementation factor
catalogue which used to be called the implementation factor assessment and
deduction matrix, but they decided to change it in version 10. The solid gap
solutions and dependencies matrix architecture definition increment stable
transition.
Estate architect the state devolution table and business value assessment
technique.
Implementation factor catalogue. Use the document factors impacting the
architecture implementation migration plan Can be used to identify What I would
refer to almost as ancillary projects, for example, if a result of a change in
technology might result in the need for redundancy or retraining of staff, the
 theknowledgeacademy
redundancy or retraining of staff may not be considered to be part of the original
project, but could be part of HR related project concerning the absolution
dependencies matrix used by the architecture group. The gaps identified in the
domain architecture gap analysis results And assess potential solutions and
dependency.
So if you've got to Say a business gap and you've got an application gap and
they're both related. If you identify an application to fill the application gap, that
voice step would address the corresponding business gap. So it makes it a bit
more efficient when you're trying to identify.
Solutions to address the gaps in the architecture, architecture definition
increments table is used by the architect to plan a series of transitional
architectures outlined in the status.
Of the enterprise architecture at specified times, that's used to create the
transition architectures and then you've got the transition architecture state
evolution table which allows the architecture to show the proposed state of the
architectures at various levels at the transition architecture point, so The
definition inference table is where you define the transitional arch.
Pictures and then the transition architecture state evolution table could be used
to show the state of those architectures at those transition architecture points.
This is the value assessment technique used in Phase F to assess the business
value by drawing up a matrix based on a value index and a risk.
Index and potentially you could use that As one of the ways to decide which
projects you wanted to run first, still not too convinced about having the in
trouble at risk and on target because it doesn't really relate to the fact, for
example, that Project D is the highest risk, but yet it's on target.
Whereas something like Project B, which is a lot lower risk, is in trouble, that
would be more indicative within flight recorder than.
Sort of strategic level planning tool, which is where this would often be used if it
was gonna be used at All but it's just one technique you could use to determine
the sequence of implementation and how the repository can be structured using
the topography architectural repository as an example.
 theknowledgeacademy
This is the suggested composition for an architectural repository. It is just the
suggestion your repository doesn't have to look like this. If you are actually
implementing an architectural repository. Practically you would probably use
something.
Like SharePoint or Rationale or JIRA or any other document management tool for
that matter. Because when you're talking about the architectural poster, you're
talking about another document storage area and quite often in the past when
I've been helping people.
Set of capabilities, it's, you know, one of the when we're talking about repository
they say or do we need anything special for the repository I said well, what do you
currently use for your document management they go SharePoint or we'll use.
All right. So it's just another, you know?
Document storage area. They've got distinct, you know, areas defined here, but it
you know you don't have to have it structured.
Exactly like this but Again, if you're not too sure to start with, then you could do
us And follow this guidance.
The architecture meta-model describes the organizationally tailored application
of an architecture framework.
Including a method for architecture development and a meta-model for
architecture content, so tells us what frameworks are in use effectively because
we got the method and we've got the content, the architecture capability at the
bottom.
So those bits in green, there is some significance in the colouring just wants the
parameters.
Purchase and processes that support the governance of the architectural
repository. So that's more sort of background information the Areas in the Blue
the architectural landscape, the standards library and the reference library. That's
the area that holds The majority of the architecture content that you're creating
or using in your architecture projects. The architecture landscape represents an
architectural presents an architectural representation of assets in use or planned
by the enterprise at particular points in time. And that from experience quite
 theknowledgeacademy
often Is referred to as the architecture projects folder or projects location or
something like that because it has the project specific documentation.
For an architecture Project The Standards Library captures the standards with
which new architectures must comply, and that can often be seen as a sort.
Of subfolder in Some cases of the reference line because it's there to be, to be
referenced. The reference library contains the OR provides the guidelines, the
templates, the patterns and other forms of reference.
Material that can be leveraged in order to accelerate the creation of new
architectures doesn't have to be templates and patterns. It could also be the area
where you put your content for reuse.
So if you've gone and created an organisational decomposition diagram for
example, and you want others to potentially reuse that with our architectural
work.
Then you could put it into the reference library for reuse.
The governance repository provides a record of governance activity across the
enterprise.
The Architectural Requirements Repository provides a view of all authorised
architectural requirements, so that's the idea of a centralised report review for
requirements and the solutions landscape presents an architectural
representation of the solution. Building blocks supporting the architectural
landscape. So in some cases that might just be called a solutions repository.
As opposed to a solutions landscape, but it's There are solutions or the data
sheets related to solutions would reside.
What to expect?
A well-run architecture repository supporting tool High-functioning teams should
be supported by modelling and analytical software as well as a document
management system. As we said before you know SharePoint rationale or
whatever practitioner.
Requires linkage between any models and documentation as well as the.
 theknowledgeacademy
Space to perform analysis Sufficient detail and well, when repository will contain
sufficient detail to demonstrate that viewers for stakeholders have derived from
the architecture.
All stakeholder concerns must be addressed. Focus on the three. The three most
powerful components of an EA repository. The Architecture requirement,
specification, controls, and gaps.
Focus on grid information management, including good information presentation
practise, how the concepts and architecture levels are used to organise the
architectural landscape Shape it's typically.
Enterprise many architectures will be described in the landscape at any point in
time to address the complexity the TOGAF standard uses the concepts of levels
and the enterprise continuum to provide a conceptual framework for organising
the architectural landscape. Levels provide a framework for dividing the
architectural landscape.

To three levels of granularity. So you've got strategic architecture, segment

architecture and capability architecture. So you could take a strategic architecture
project for example and divide it up based on time and breadth of coverage.
And that will.
Create the segments and the segments are made broken down into capability
architecture projects. Each architecture typically does not exist in isolation and
does therefore sit within a governance hierarchy. Broad summary architectures
set the direction for narrow and detailed architecture. So, as we go further down.
Get down to the capability architecture. That's narrower and more focused, but
still within the context of an overall strategic architecture.
Two strategies can be applied to architectures at different levels and can be
developed through iterations within a single cycle of the Adm process.
Or you can develop them through a hierarchy of Adm processes executed
currently with one architecture project triggering another, organising the
landscape, the breadth or the subject matter area is generally the primary
 theknowledgeacademy
organising characteristic for describing an architectural landscape. Architectures
of functionally decomposed.
Into a hierarchy of specific subject areas or segments The depth with broader
subject areas obviously is less detail and obviously, if you get more go further
down than you.
Get more specific and that will generally permit more detailed architectures.
Time for a specific breadth and depth and enterprise can create a baseline
architecture and a set of target architectures that stretch into the future.
Again, broader and less detailed architectures were generally valid for longer
periods of time and could provide the vision for the enterprise that stretches
further into the future, IE strategic architecture, recency. Each architecture view
will progress through a development cycle where it increases in accuracy until
finally approved.
After approval, the architecture will begin to decrease accuracy. If not actively
maintain Pain and in some cases reasons you may be used as an organising factor
for historic architectures, so it's important that we understand not only what's
been modelled, but when, as it's been modelled or when it's supposed to, to
represent different levels of architecture that exist in an organisation. We've just
mentioned. The fact that we've got strategic architecture providing.
Organising framework for operational and change activity and allowing for
direction setting and executive level segment architecture provides an organising
framework for operational and change activity and allows for direction setting
and the development of effective architecture.
Perhaps at a programmable portfolio level and then capability architecture
provides an organising framework for change activity and the development of
elective Rd maps.
Realising capability increments, there is a there is almost a a sort of inference that
the capability architecture could be a single project and it could well be a single
project. But Been down at the capability architecture level, it may well be that the
capability architecture is still being realised through some programme rather than
 theknowledgeacademy
it being necessarily an individual project. The architecture continues and provides
a method of dividing each level of the architectural landscape by abstraction.
Office a consistent way to define and understand the general rules, relation
representations and relationships, including traceability and derivation, insurance
relationships from foundation elements up to organisation specific. But despite its
rather fancy name of architecture, a continuum.
It is largely just a classification schema Determining the level and architecture is
being developed at within your landscape. Looking at the figure, the essential
point is that the architecture project covers a specific portion of the EA landscape,
defining defined regarding breadth, planning, horizon and detail.
Well, prior work may already exist within the scope, so where does it fit in to the
overall landscape? One of architecture building blocks architecture build which
relates to the architecture continuum and I defined or selected the result of the
application of the Adm they used to capture architecture requirements e.g.
Business data, application and technology.
They direct and guide the development of the solution building blocks, though it
could be that an architecture building block might be that.
We need a Mail service and the solution could be a web-based mail application or
it could be.
Exchange, Microsoft Exchange or what?
Guidelines and techniques for business architecture, applying business
capabilities, and business capability map found or developed in the architecture
visual phase provide a self-contained view of the business that's independent of
the current organisational structure. Business processes, information systems and
applications and the rest of the product.
Or service portfolio. Those business capabilities should be mapped back to the
original organisational units, value streams, information systems and strategic
plans within the scope of the enterprise architecture.
Project this relationship mapping provides greater insights. The alignment and
optimization of each of those domains. They've produced a series guide for
 theknowledgeacademy
business capabilities which is G211, so focusing on different ways to visualise the
business capabilities.
That's an example of business capability. Maps are the major business
capabilities, strategic core and supporting and that's a business capability that
heat maps.
It takes the same information that we had previously, but it then puts various
colours on and this could well be a business capability.
Heat map that's showing the maturity of the different business capabilities.
I've got a Feeling I'm pretty sure that the customer management the way in there
is incorrect. It doesn't fit in with anything else on here I mean, this was produced
by the, you know By the open group, but I think that should have really been an
end to falling in line with the others because using this sort of heat map, the
green normally indicates that the capability.
Is mature, and doesn't really need any work at The moment so the urgency is low.
So the yellow indicates that you Know it's Almost there, but needs a bit of work
doing to it.
So the maturity is medium, hence the yellow in colour. The red indicates areas
that really need work on at the moment, so the idea is to focus the efforts on
improving the areas that are in red.
There the, the, the higher urgency, there's this, you know, lacking in the maturity
of those particular capabilities. And then the purple, the colour in the with the N
indicates that's a new capability that we don't yet have that we would want to
attain at some point.
So the why for the customer management, I think it's just a typo and that really
should be umm like the other yellow ones and that would make much more sense
if you have a look at the G211, you can see the same example without the letters
and the brackets on.
It says different heat maps can be generated from the same business capability
map depending on what criteria and perspective or lens the business wishes to.
 theknowledgeacademy

Why it could Show the strategic contribution revenue contribution, cost,

contribution coverage and so on. So there's there are different views that you can
have the different lenses you can apply, but having the same colour one would
you know it really you know suggests that they put the wrong letter.
On to their When they put the additional text Applying value streams value
streams provide valuable stakeholder context.
Into why the organisation needs business capabilities, what business capability
should provide, what the organisation needs for a particular value stage to be
successful.
Start with the initial set of value stream models for the business documented in
the architecture vision phase within the scope of the specific enterprise
architecture project, if sufficiently larger.
In breadth, there may be a need for new value streams, not Already in the report.
Tree your existing value stream can be analysed within the scope of the project
through heat mapping or by developing use cases around the complete definition
of the value stream and this is showing a value stream with the capabilities
mapped to the different stages of that particular value stream applying
organisation.
Paying an organisation map shows the key organisational units, partners and
stakeholder groups that make up the enterprise ecosystem. The map should
depict the working relationship between those entities as distinct from an
organisational chart that typically only shows a hierarchical reporting relationship.
The business unit is the main concept used to establish organisation maps. This
map is a key element of business architecture because it provides the
organisational context for the whole enterprise architecture effort and it could
look a bit like that. So looking at the Connexions, the connectivity between the
different.
Business units applying information map Characterising information in the
business architecture phase starts with the elements that matter most to the
business. Maybe product, customer factory, etc.
 theknowledgeacademy
Relationships among the information domains can then be added to the map.
That's the next level of understanding for a good baseline information map, but
significant benefits.
Comes with building matrices between information and business capabilities.
These information maps and relationships will then apply in later phases to the
data characterization applications and infrastructure, and that's the simple
information map Blaine, modelling techniques, modelling and mapping
techniques for extensions that implement the business capabilities, value streams
and organisation.
Helps activity models also sometimes referred to as business process models,
describe the enterprises business activities, the data and all information exchange
between the activities. So it's internal exchange.
Is and or the data information exchange with other activities outside of the scope
of the model. So external exchanges use case models to describe the business
process and enterprise in terms of use cases and actors corresponding to the
business processes and organisational participants. Logical data model or class
data model.
Describes the entities, their attributes, and the acceptable values for these
attributes.
Foods and business models provide a powerful construct to help focus and align
an organisation around its strategic vision and execution.
This is an example that a business model canvas and this came from another.
Business-related Series Guide which is Business models G18A.
G18A, if we go and have a look.
Here at G18 now you can see there the business model canvas.
So let's just expand that a bit. So it says in the figure we have a generic
representation of the retail business model and its current state, meaning it
represents how the business has been.
 theknowledgeacademy
Delivering value for the last several years or made to understand the model is to
read from the customer's perspective, from right to left. Seeing how the business
strives to serve both the mass retail shopper market and provide some regional.
Store shop fronts and the ability to find inventory ahead of time through the
Internet. The business intends to provide greater value than the competition
through lower prices, personalised help and a better product range.
To achieve this, they must have stronger customer analytics, maintain their brand
and facilities and keep strong partnerships that lead to the right.
Products through the right suppliers to meet those customer needs. So this is one
way of showing the business.
This and how it's tillering value, but again, if you're interested in more detail
about business models then you can go and have a look at G18A business
capabilities in G211, applying gap analysis key step in developing and architecture
is to identify.
Changes between the baseline and target architectures using gap.
This is a gap analysis technique is used to Consider what may have been
Forgotten or missed as well as what is needed.
A gap is simply anything that changes. You could draw up a matrix with all the
architecture building blocks of the baseline architecture on the vertical axis and
the.
Arctic buildings with the target on the horizontal axis. This is talking about
creating a gap analysis matrix. I'm not gonna go through all the detail there
because, for the majority of people, the idea of having a gap analysis matrix is not
particularly the best way of.
For depicting gap analysis, typically you'd have just three columns with baseline
or as-is target or TB and then gap column and then free trade.
You just compare and then within the gap row. You'd say whether it was a gap or
is it there. There's no change or something new It's a lot easier way And a lot
more convenient but Yeah, this, this, they seem to be persisting in this sort of idea
of putting it into a matrix which I've never found particularly useful.
 theknowledgeacademy
Not that you need to know any detail about the. Putting it into making drinks, but
if you wanted to then that's the detail there.
Alien faces BC and D developed the target baselining gap just enough for the
purpose. If the current state is accepted, the only reason to describe the baseline
is to Develop the gaps.

Consider the limitation of restricting description to where there is a gap

description using the same technique at the same level of detail and able to the
identification of gaps.
That gap is anything that changes how iteration can be used in architecture
practices. Iteration can be used in two different ways. Iteration of the Adm.
Described in terms of activity re-sequencing and looping, the Adm is rated in
terms of information flow by exploring the EA landscape based on the
information required.
If the information required is available, moves on and was produced the material
by exercising an Adm phase, the Adm sports iteration in a number of ways.
The iteration is quite a comprehensive architectural landscape through multiple
Adm cycles based on individual initiatives bound to the scope of the request for
architectural work iteration.
Describe the integrated process of developing an architecture Where the
activities.

You described in different phases interact to produce the integrated architecture.

And its relation to describe the process of managing change, that's the iteration
to develop a comprehensive architectural landscape. So projects will exercise
through the entire radium cycle, commencing with phase A.
Each cycle of the AD will be bound by a request for architectural work. The
architecture output will populate the landscape start at the strategic level. You
can go around doing whatever phases are necessary and you don't have to do
every phase every time.
 theknowledgeacademy
Of course, to strategic level, the focus might be on business architecture. So you
know you could skip phases C&D and then go around to E&F and then from there,
taking the strategic architecture, you could break it down by going into segment
architecture cycles and then eventually down into capability architecture cycles
and that's how we can get potentially get the three-dimensional landscape that
we saw earlier.
Separate projects may operate their own Adm cycles concurrently with
relationships between the different projects. One project may trigger the
initiation of a another project when it comes to iteration, you can one of the
considerations is whether you do the baseline architecture first or the target
architecture first. And this is just showing the target, although they could quite as
easily have shown the baseline, because that tends quite often to be the
preferred approach to doing the baseline first, because quite often it's difficult to
come up with the target if you don't know where you currently are. But it doesn't
have to be a case of doing baseline target for all four domains. It could be that
you do the all the baselines and then go back and do all the targets. Or in this case
to all the targets and then do all the baselines.
So when it comes to iteration, pretty much anything goes iteration within an Adm
cycle architecture development iteration. You can operate multiple Adam phases
concurrently cycle between the Adm phases, return to previous phases to update
work products with new information. And we have major iteration loops within
an Adm cycle as we can see there and as we have seen previously, iteration to
manage the architecture capability projects may require a new iteration of the
preliminary phase to reestablish aspect. That the architecture capability identified
in phase A to address a request for architectural work, new iteration of the
preliminary phase to address the organisation, architecture capability and result
of identifying new or change requirements for architecture capabilities. So if we
get a change request coming in which would go to phase A to trigger phase A,
then you might need to go back and revisit the some of the activities of the
preliminary in terms of your architecture capability.
Classes of architectural engagement standard defines approaches for different
areas of engagement, identification of change required, definition of change and
implementation of change. They need to change iteration focus for classes of
 theknowledgeacademy
architecture, engagement, some information that's and extract from the
engagement information.
Iteration in terms of information flow iteration within the Togaf Adium is often in
terms of resequencing and looping. Iteration can also be done in terms of
information flow or iteration is driven by the information needs of the project.
And if the information required is not available, then it's produced by exercising
the togaf Adm phase, and we can, you know, do the phases of the AD and then
recycle through them as necessary how the implementation factor catalogue can
be used? There was a mention of this earlier when we're talking about the
migration planning techniques. This catalogue can be used to document the
factors impacting the implementation migration plan created at the start of Phase
E to act as a repository for implementation and migration decisions.
Catalogus revisited during phase as further information is found and I was saying
before that it could be used to identify additional projects such as providing
training for personnel or redeployment of staff. What some people might
consider as silly re projects that are not directly. Lot of the main project but
related to it consolidated gap solutions and dependencies matrix allows you to
gather together the gaps identified in the previous phases in phase BC&D.
Use as a planning tool when creating work packages and that as the architecture
group that gaps identified in the domain architecture gap analysis results and
assess potential solutions and dependencies to want more gaps, architecture
definition increments table. That's the table you could create to your transition
architectures based around the deliverables from the architecture project.

Table used to plan a series of transition architectures outlined in status of the

enterprise architecture and specified times can be used to assign incremental
project deliverables across the transition objects. The transition architectures
typically will get defined by the creation of the outputs from the various projects
and that will then allow you to have the transition architecture points, content
framework and the enterprise meta model.
The need for the content framework and the enterprise meta model and task
when establishing the enterprise specific enterprise architecture capability in the
 theknowledgeacademy
preliminary phase is to define a categorization framework to be used to structure
the architecture descriptions, the work products used to express an architecture,
and the collection of models that describe the architecture. So the content
framework and understanding of the types of entities within the enterprise and
the relationships between them that need to be captured, stored and analysed in
order to create the architecture description.
This enterprise meta model depicts the information as a formal model, so it's very
much as its name suggests, as a meta model and model of how to model value
gives architects and start a set of the types of things to investigate and covering
the models provides a form of completeness cheque for any architecture building
language or architecture metal that's proposed for use in an enterprise. It can
help ensure consistency, completeness and traceability.
A list of example modelling approaches is included in the handout useful to
describe something consistently. The approaches may have formal informal
mental models, notation or supporting methods, and if we go into here and look
at we have a list of some of the models or modelling techniques archimate
standard business model, canvas, business process, model notation.
UML, so all sorts of possibilities. Anything then modelling within an organisation is
having consistency of the tools that you're using.
When the architecture content framework needs to be filled throughout the Adm
cycles at each stage the Adm requires information as inputs and will create
outputs as a result of executing a number of steps.

The content framework provides an underlying structure for the Adm that defines
inputs and outputs in more. Tail and puts each deliverable into the context of the
holistic architecture view of the enterprise that actually shows the default
building blocks that you would have in the meta model as part of the content
framework. And then you've got here descriptions of the different parts of that
model architecture principles, facial motivation requirements models are
intended to capture the surrounding context of formal architecture models,
including general architecture principles, strategic context that forms input for
architecture, modelling and requirements generated from the architecture.
 theknowledgeacademy
The business architecture captures architecture models and business looking
specifically factors that motivate the enterprise and structuring capabilities.
Information systems, architectures, capture architecture models, IT systems
looking particularly at applications and data technology architecture models.
Not surprise, the technology assets used to implement the realise the information
system solutions architectural realisation and transformation primarily sort of
maps to phase three and F of the AD.
Capturing change road map showing transition between the architecture States
and the change management models. Models capture value, realisation
management events, internal and external to that impact the enterprise
architecture and the generation of requirements and there's mapping or the gay
capability development with the Adm phases showing the various the contexts
and that's available in the handout as well using an enterprise meta model this is
the full enterprise metal model.
The idea behind it is that it allows you to model your building blocks your entities
in a consistent way and it shows very much the relationships between the various
default entities. So you've got at the top, for example, a driver which creates a
goal. A goal is made specific with an objective which is tracked against the
measure and you can go in both directions. If you follow the lines as you start at
one end and say and act consumes you know data entity or the data entity supply
to the actors and you know actors and events and roles.

The idea is that that by providing this, it hopefully will give you a more consistent
modelling of your architecture element and this is just an extract. There's lots of
entity descriptions as part of the meta model and also showing the relationships
as well. Using a taxonomy, Tony have enterprise metamodel provides a good
starting point for taxonomy. For the majority of enterprises it defines a list of
common components and common possible relationships the enterprise may
want to keep track of renovation role, event activity, location, resource, platform
services and set of relationships. And again, there we have the mental model
describing the entities, the attributes and the relationships. How risk assessment
can be used risk assessment.
 theknowledgeacademy
Generally accepted areas of concern for security architect and risk assessment is
part of it determining what risk we face, measuring them to determine their
likelihood and impact, and then accepting, mitigating or transferring the risk,
according to the organisation risk appetite. And that's from the series guidance,
rating, risk and security V152 there are no hard and fast rules with respect to
measuring effect and frequency. The frequency term is what they use here
instead of probability because in most risk management methodologies that I've
come across in the past.
Must they tend to refer to probability and impact? And they decided to use
frequency and effect to effect is what we would normally have as the impact and
the frequency is what we would normally call the probability. And it says the
following guidelines are based upon existing risk management best practises.
Hmm. Yeah, maybe not once that I've come across per statement. There we go
the active assessing risk risk assessment is the activity in terming the risks that are
relevant to an asset or objective, A qualitative risk assessment delivers a listing of
relevant risk scenarios with a high level prioritisation.
Whereas A quantitative approach seeks for numeric determination of the risk
adorable of a risk assessment is the business risk model. This mitigation plan
contains activities to mitigate risks. It's the implementation of the risk
management strategy which could aim to increase the level of control, transfer
the risk to another party, avoid the risk by changing the business activity, delay
the risk, compensate for the risk, et cetera.

Poor sensor risk is addressed by the enterprise risk management process in

phase. The scope includes the latest information security risks as identified during
the risk assessments done in earlier phases, in particular in Phase B in Phase F
migration planning migration is itself a business process that needs to be secured.
Migration strategy should include a risk assessment and a risk mitigation plan in
phase after risk mitigation plans limited to the transition. In addition, migration
planning should include a security impact analysis to understand any security
impacts of the target state of the change.
 theknowledgeacademy
And there is one practise learning, study exercise or question in the learning
studies document there. So again 10 minutes to give that a go and work out what
you think the best answer is to that particular question summary then The
learning units completed. So we've had a look at all of those units in this
particular course.
Unit 1, the context for enterprise Architecture Unit 2, stakeholder Management,
Unit 3. Phase A, the starting point. Unit 4 Architecture Development Unit 5.
Implementing the Architecture Unit 6. Architecture change Management Unit 7.
Requirements management and Unit 8 supporting the AD M work and
congratulations on completing this course and good luck with the certification
exam.