Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.



This PEZ is used in the course EH2770: IT Management with Enterprise Architecture I, at KTH Royal Institute of Technology, Sweden.

Mathias Ekstedt

on 8 April 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of EH2770

Knowledge block: EA analysis
Welcome to the course
IT Management with Enterprise Architecture I
- What is the course all about?
- How is the course designed?
Imagine a large enterprise...
Think about everything that is needed to get it going...
To produce:
Etc, etc...
If you are responsible for making sure the enterprise works...
How do you behave..?
Well, how do other people working with complex things behave?
A doctor
A car mechanic
They use some sort of abstracted support for their work
A map
A model
But this guy...?
He also needs help!
Enterprise Architecture - A Map of the Enterprise
Welcome to the Castle of Enterprise Architecture
This is where we keep all the knowledge for the course
In order to navigate through the knowledge landscape in the EA castle you of course need a map of it!
Enter here!
Take a look:
In this course you will do most of the learning together with fellow students in your group and here, online. Not on lectures.

This presentation, called PEZ, is intended to be your guide through the course. It describes what to learn and suggests an order. So, it gathers and relates course material for you. It includes text, pictures, videos, and pointers to course literature and web pages. (All material is available from the KTH network, most material is available from anywhere.)

You will meet the course teachers for group tutoring sessions, a mid-course seminar and for the final presentations. There is also an option to request lectures. There will be a set of guest lectures with external speakers.
Not perhaps the standard course set-up...
- To the content of the course
Models, models, models...
Enterprise architecture makes the fundamental assumption that the complexity of an enterprise is well- captured in a diagram of boxes and lines. This could of course be questioned - but in this particular course we don't!
Views and viewpoints
Think about it! Isn't it amazing that all the companies and professional organizations in our society actually produce and deliver things? Think about all the stuff and people that need to be in place for you to buy a pair of shoes, or to take the train to school in the morning, or talk to your mother over the phone. All of these things and people are really designed to provide you with a service or product. Like small cog wheels in a gigantic machine... (And even more, how these large organizations collaborate in extensive value chains.)

What if someone or something started misbehaving or just behaved differently compared to what is expected, like if the size of a wheel was suddenly changed..?

How do you make sure they don't? How do you get an overview of all the people and things in a large enterprise? So that you can make sure that things are running smoothly. Or even better; enhance the machinery.
You're right - very exciting!
This PEZ includes a presentation path (which you probably are following the first time you read this). This is to guide you through the material and give you an overview. The path follows logical order on how to approach and read the material. If you follow it you have read all necessary prerequisites at every step. However, when working in the course in practice, it is not recommended that you follow this path every time. Instead you should take control over your own learning. Maybe, or rather most probably, you need to revisit some places in the middle of the path several times. You can zoom, click, read and play in any order you like. You can also jump back and forth in the presentation path with the tool bar below. You can "join the path" anywhere at any time when you need some additional guidance.

We strongly recommend that you take control over your learning and start exploring the material yourself!

And remember!
This PEZ covers material for the whole course so it should take you days (or weeks) to take it in, not an hour or two.
How to use this PEZ
This course is organized in different knowledge blocks. These blocks are all outlined here in the different "rooms of the castle" with a number of smaller modules.

The course have the following four main knowledge blocks:

The complexity of enterprises and the challenge for EA
Basic EA modeling
EA analysis
EA transition planning

The following knowledge blocks are also briefly touched upon:

EA frameworks
EA governance and organization
EA work in practice
As you recognize the viewpoints are similar to the idea of a meta model in the first place, cf. figure below. Viewpoints are subsets of the meta model rather than the reality.

Model objects and relations are thus typically part of several views
Enterprise Architecture Views Properties

A background: The idea of abstraction
Goal: You should be able to describe why increasing complexity create a need for models

Syntax vs. semantics
Goal: You should be able to explain these two concepts and how they apply to architecture models

Models vs. meta-models
Goal: You should be able to describe the difference between these two concepts and apply them consistently

Enterprise architecture meta models
Goal: You should be able to describe what an EA meta model (language) typically consists of

Viewpoints and views
Goal: You should be able to describe what a viewpoint is, how it relates to meta models and views

Granularity and reference architectures
Goal: You should be able to describe what reference architectures are in relation to meta models / models and how they may differ in granularity

ArchiMate in summary
The meaning of words and sentences:

The Bird in the tree

"Colorless green ideas sleep furiously"
Syntactically correct, semantically meaningless…

In architecture, again:
What do boxes mean?
What do circles mean?
What do arrows mean?
What do colors mean?
Semantics (meaning)
Originally used in linguistics (study of languages) for the rules that dictate how sentences may be formed from accepted words.
the bird in the tree – correct
the the bird tree in – incorrect

Architectural models also have a “language” with syntax that dictates what is correct and not.

The most prominent general syntactical rules are (not always true, however…)
Boxes may not be connected to boxes
Lines may not be connected to lines

The “words” of architectures are usually more refined than boxes and lines, e.g.
Colored boxes, circles, dashed arrows, “clouds”, etc.

Syntax (form)

The system contains
the following information:
- sales plan
- forecast
- …

Several users are allowed to read and write the information, namely:

Information is stored in…

An alternative model could be:
EA assumes:
Pictures are better suited for getting a holistic understanding of the enterprise than text (an other model formats).

Architecture can be seen as the ”mathematics of information systems”
EA models are box-and-line based!
Class-based - what has been described so far
Business Process
Organization (governance) structure

Object based scenarios - all or a few of the objects related to some specific object(s). E.g. classes related to a process:

Stakeholder/concern-based - often related to some
property(ies)/attribute(s) of the objects
Information Security
System Maintainability
System Availability

Types of viewpoints
This is what EA models practically may look like!
(sort-of-boxes and sort-of-lines…)
There are may types of models… - You can probably envision the reality that all of these models depict
We focus on what is relevant
Sometimes the system does not exist, we think about what it could and should be like

Architectures are idealizations of the real world




How to cope with the ever increasing complexity?

(I.e. a system model in our case)
Syntax can be more or less self-explanatory
Different syntax may have the same semantics
Mapping between Syntax and Semantics

What do boxes mean?

What do arrows mean?

Are some entities detached?

What does the yellow circle mean?

But what do they mean...?

Knowledge modules
The idea of abstraction
Idealizations of enterprises.. ?
most important aspects of the system
The use of models
Prediction of system
Design decision:
division of functions
available technology
Meta models vs. models
(These tools are typically becoming better over time.)
First, read marked text:
From: IT Management with Enterprise Architecture
Then some pictures saying the same thing
Syntax and semantics
Chomsky 1957
The mapping is arbitrary - something someone just decides!
Continue reading here
Ok, you can stop here in the book for now. First, meta models and models are further illustrated in some additional pictures. We will then, in the next module continue with looking a bit deeper in to the above-mentioned ArchiMate specification.
This is an example of a meta model
Meta models consist of
In addition, a
describe how many relations there could or must be between classes, e.g.
an employee must be employed at exactly one company
a company could have between 0 and infinity employees
an employee could work on between 0 and infinity projects
and a project could have between 1 and infinity employees
(in this example below)
Right! This relation is not allowed by the metamodel
You should be able to describe why increasing complexity create a need for models
You should be able to explain the syntax and semantics and how these apply to architecture models
Enterprise architecture meta models
Meta model and model examples
And note! The meta model and model consistency is just a syntactical check, it has nothing to do with reality as such. Mr Cortright was for instance indeed the chairman of the Apollo 11 project. And if someone modelled the Appollo 11 project running for 12 days in 1971, this would be OK with respect to the meta model.
For those of you with a computer science background you will recognize this whole idea. It is very similar to class and object modeling in object-oriented programming paradigms (for instance with UML) or information modeling for databases (for instance in ER-diagrams). However, the purpose in EA is not to generate code but to use it as support for understanding and analyzing an enterprise. Conceptually its more similar to for instance a building construction blueprint.
You should now be able to describe the difference between models and meta models (model languages) and apply them consistently
You should now be able to describe what an EA meta model (language) typically consists of
Again, however, remember ArchiMate is one example of an EA meta model. A slightly different one will be used in the course.
In order to understand what an EA modeling language looks like we will now return to ArchiMate.

The ArchiMate 2.0 Specification is available in PDF on KTH Social. You need to download it separately outside this Prezi.

ArchiMate is just an example but a very representative one. ArchiMate is not explicitly used in the course, but a modeling language looking quite similar. In practice however, ArchiMate is arguably the most common state-of-the-art EA language, so it is worthwhile studying it a bit extra just for your future career!
Reading guidelines
First, read the introductory chapters 1 and 2 according to the following recommendation:
Chapter 1. – Read all
Section 2.1 – Read all
Section 2.2 – Read all
Section 2.3 – Read as extra material
Section 2.4 – Read all
Section 2.5 – Read all
Sections 2.6 – 2.9 – Read as extra material

Chapter 3: Business modeling
This chapter describes business-related concepts. The purpose of reading this is to understand what business-related concepts that are typically modeled and what they mean. Here you get the answer to questions such as ”what does business process mean?” In essence, read the ”framed” parts of every section (the definition and an example.) The very, very brief summary is found in Section 3.5.

Chapter 4: Application modeling
This chapter describes software application-related concepts, i.e. the interface of IT-systems that the business see/use. The purpose of reading this is to understand what application-related concepts that are typically modeled and what they mean. Here you get the answer to questions such as ”what does application service mean?” In essence, read the ”framed” parts of every section (the definition and an example.) The very, very brief summary is found in Section 4.4.

Chapter 5: IT-infrastructure modeling
This chapter describes concepts related to the underlying IT infrastructure, i.e. all the things that users do not really care about directly but is essential to run applications. The purpose of reading this is to understand what IT infrastructure-related concepts that are typically modeled and what they mean. In essence, read the ”framed” parts of every section (the definition and an example.) The very, very brief summary is found in Section 5.5.

Chapter 6. ArchiMate Layer dependencies
As is hinted/described in chapter 2 ArchiMate is one single EA language/metamodel. In chapter 3-5 the different layers were described as standalone meta models. In this chapter they are tied together. Conceptually this chapter brings nothing new. It can be read to get the complete picture of ArchiMate.

Chapter 7: Relationships
In chapters 3-5 only classes were described, the relationships were just briefly mentioned. Of course, also the relations have explicit meanings. Read sections 7.1-7.3 just as you did with chapters 3-5, i.e. read the framed text for the definition and examples of relations. And again, these are ArchiMate relations use them as examples of common relations, but there are others in other languages/metamodels. Summary is in 7.4. (You can easily skip 7.5)

Yes, multiplicities and attributes...

But this is just a simplified picture!
Something missing?
EA models quickly become extremely complex...
Imagine a larger company with many employees, a complicated business, thousands of IT-applications and even more IT-infrastructure components....
This is a "toy" EA model example taken from a commercial EA tool that describes a heavily simplified bicycle manufacturer:
Obviously, this kind of model doesn't make anyone happy...
Don't model everything at once - use views!
EA views more formally
Given this
meta model
We can decide to
just show a well-
defined subset
leading to e.g. this kind of model
- a view!
The terminology is the following:
are subsets of
meta models
are subsets of a
(conforming to the viewpoint)

In practice, however, views and viewpoints are not used in this strict way but sometimes interchangeably

Yes, models get messy, but more specifically different people are interested in different things and the same person is interested in different things at different times.

An architectural view is a model that describes a specific set of concerns of the specific system
Cf. plumbing, electricity, and carpenter building blueprints for a house

At the same it is of cours important that all the different stakeholders work with the same underlying model. Otherwise it would be difficult to avoid having a water tap and electrical outlet on the same physical location...
Why views?
More on viewpoints and views
Read chapter 8 in the ArchiMate 2.0 specification (available on Bilda).
Sections 8.1-8.3 provides a background to Views/viewpoints and also outlines different stakeholders and their interest in different EA views.

Just as the ArchiMate as a whole is but one of many EA languages, but a particularly poular one, so are of course their views.

In section 8.4 the viewpoints are presented. Browse through and look at the viewpoints (figures labeled "Concepts and Relationships") and example views (figures labeled "Example")
The concern-based view is the main topic of this course.
Because it is of utmost importance to provide information that is of
to stakeholders, not just information that happened to be available...
More on this later on...
You should now be able to describe what a viewpoint is and how it relates to meta models and views.
Granularity and reference architectures
How specific should the meta model be..?
There is no given answer to this question...
We can almost always create sub-categories of classes.
An Operating System is a kind of Infrastructure Software System which is a kind of Software System which is a kind of...
...which is a kind of class.

The "is-a-kind-of" relation is defining the granurality of the classes in a meta model
on the other hand is where we go from meta model to model
An instantiated object is something that represents something specific existing in the enterise while the metamodel contains conceptual phenomena
Again, the distinction is not possible to make in a universal way. At Microsoft Windows 2000 typically is (was) a specific product whereas on the user side it could (sometimes) be considered as OS category
Again, so where to draw the line is arbitrary...
And the choise of how specific/granular the instantiated objects in the model should be is arbitrary too
Reference architectures
In the twilight zone between meta models an models we find reference architectures. These are listings of sub categories of more abstract classes that typically are seen as suggestions on what could be modeled as instantiated objects in a model.
One of the more spectacular reference architectures is found in the "
Federal Enterprise Architecture Framework" (FEAF)
. Here you can find listings of all the "businesses" that the USA is involved in. Postal Services, Higher Education, Cultural and Historic Preservation, Crime Prevention, Health Care Administration to mention just a few... It can be noted that these are of course all extremely complex enterprises in them selves.
FEAF also include a Service component reference model and a Technical reference model with application services and IT-infrastructure components respectively

More info on http://www.whitehouse.gov/omb/e-gov/fea
Also TOGAF (pdf available in Social or online at: http://pubs.opengroup.org/architecture/togaf91-doc/arch/) includes reference models (part IV page 489). In particular TOGAF includes a reference model of Technical IT-infrastructure components and solutions, section 43.5 page 506 and section 44.3 page 531.
Now, there exist many other reference architectures/models.
For this course you can use such reference models as a source of inspiration
for figuring out "how enterprises typically work" and thus sort of a library of components for your own EA models.

I EA work in enterprises reference models are typically used for finding an appropriate level of abstraction. Also, many enterprises develop their own reference architectures. For instance the different national divisions perhaps deploys similar but slightly different solutions.
You should now be able to describe what reference architectures are in relation to meta models / models and how they may differ in granularity
Knowledge block: Basic enterprise architecture modeling
sub divided into
Summary of knowledge block
Roughly this knowledge block could be summarized with the following diagram (or "almost" meta-model, you might say)
In the next knowledge block we will continue to talk about analysis of EA models
Knowledge modules
Course administration
Another EA model example
Have a look at the example on this web page:
QualiWare is a company that sells an EA modeling tool. This is an example case describing a fictitious car manufacturer. It is of course heavily simplified since the purpose of it is to illustrate how the tool can be used.
For our current context it could also serve as an example of another EA modeling language. As is very common in practice, this example does not explicitly state what the used meta model looks like. Instead it needs to be understood along the way. (As an exercise you can see if you could write down the QualiWare meta model.) But as can be seen in the example the scope and the classes are quite similar to ArchiMate. (Click on the grey boxes; "strategy", "organization", etc., to get started exploring the EA models.)
Knowledge block: The complexity of enterprises and the challenge for EA
Unless you have already done so please browse through the introductory part of this course (in the upper right corner of the PEZ). It will give you the motivation to the topic of EA from the point of view of this course. Now, in addition to this please take a while to look at the following two videos that will introduce EA in a more general form.
First look at this:
Then look at this:
Second time you are here! Now, do the videos bring new insights?
read sections 1, 1.1 and 1.2 in the book
IT Management with Enterprise Architecture.

Book available on KTH Social.
If you are interested in an introduction video on ArchiMate, here is one:
Below there are three videos on IT components and common IT architecture solutions. These are nice illustrations. However, just as previous material it does not describe if and why the described solutions are difficult to actually get in place. It all sounds easy here, but most often it is not in practice...
Enterprise Architecture means many things when spoken of. If enterprises are seen as an amalgamation of people, work tasks, physical assets, information, IT-systems, etc., the word architecture sometimes refer to the structure of all of these things and how they are related – the enterprise has an architecture, one way or the other. Sometimes the word architecture refers to the models/diagrams/pictures of the enterprise – architecture is the projection of the real world onto, say, a piece of paper. This is the main usage of the word in this course
But, enterprise architecture could be seen as a process or set of activities that the people working with EA does including who is responsible for what EA actions and decisions. This is probably the most common use of the word in practice. Yet others mainly refer to EA as the tools that the Enterprise Architects use when doing their work. EA frameworks is an example of such a tool.
How EA is (supposed to be) executed and organized in companies and how architects (are supposed to) work, are briefly introduced in the below videos. Relevant reading is also found in TOGAF Part VII Architecture Capability Framework (page 543). TOGAF is available on Social.

Since EA governance and organization is not the main topic of the course this is to be considered extra material, though.
SAP is German company that develops a kind of software that is known as an Enterprise Resource Planning (ERP) system. These systems essentially tries to contian and integrate all (the majority) of the information about the enterprise’s information and work processes in a single seamless way.
At http://www.sap.com/solution.html the company provides descriptions of how many different companies in many different domains work . In essence we can interpret this as the main processes of companies. Take look around at this website to get inspired to understand what different kinds of enterprises do and how. The web page includes videos, text descriptions, real case brochures etc, etc. Use this as inspiration to envision the complexity of enterprises. What are the information needed to have the enterprises working the way SAP say they do? What are the processes? Who is involved? What are the ICT infrastructure needed?
Now, SAP is a commercial company, they want to sell more systems so they want this to look good. To actually get ERP systems implemented and work well in an organization is very challenging (Many, many projects have failed here...). So of course you need to be critical while looking here. Think of it this way: you are the CIO of a company and the SAP (or any other ERP vendor) sales team has just arrived you must get your own understanding of how all of this work. You cannot blindly trust them it is that easy.
Another note, from the sales presentation of the ERP vendor it sounds as if their system can solve all your problems in a single gigantic system. This is of course not true! In actual enterprises there are typically several ERP systems in the organization (Remember previous videos..) And even if you mange to put much inside one large ERP-system, the interior of theat systems becomes so complex that it also needs to be managed and modeled…
Knowledge block: The complexity of enterprises and the challenge for EA
Try it your self!
Load the MAP class model in the EAAT Object modeler and follow the exercise in Chapter 2.2 in the
IT mgmt w. EA
Mixed architecture

Suite architecture

Islands of Automation

EA is (becoming) an established discipline for both business and IT management.

Architecture models constitute the core of the approach and serve the purpose of making the complexities in the real world understandable and manageable.

Enterprise Architecture

Broker architecture

Spaghetti architecture

Enterprise Information Systems

”You can use an eraser on the drafting table or a sledge hammer on the construction site.” – Frank Lloyd Wright (American architect)

Architecture models have three main functions:

Enterprise Architecture

Contemporary enterprises depend on IT systems
Number of systems increasing
More integration, tight coupling

-> Managing IT systems is important, but complex

Complex architectures, challenging management

Enterprise Information Systems

Robert Lagerström

The Royal Institute of Technology

Enterprise Architecture Analysis Introduction

“If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.”
– Gerald Weinberg (system developer and author)

Architecture vs. architecture







Decision-making process

Knowledge block:
EA transition plans
Knowledge block:
EA work in practice
Knowledge block:
EA governance and organization
Technology is moving fast and is today enabling many new types of businesses and business models. A common buzzword for this future is "smart". There are smart cities, smart transportation, smart houses, smart power grids, etc. One common denominator for many future business models is extensive use of internet connected devices. The internet of things (IoT).

An overview of standard IT-systems and services that are used in most offices :
So far we have talked about models. What they are and how they work. But what are the models useful for? Yes, we have been saying that you get an overview of the enterprise and how all it's components relate. This is of course very important. However, one of the key issues in this course is that EA models should be helpful for a decision maker to make an effective design with respect to the enterprise's needs. Understanding is good, but for the enterprise to evolve, well directed action is needed. To be able to
EA models with respect to if they are good or bad, then becomes key. If you can predict the properties of the enterprise then you can make a good design and take good decisions.

In this block we will introduce the EA modeling language and the EA tool that you will use for the assignment in the course. The unique feature of this language and tool is that they enable you to do automated analysis in the models. ..Yes, very handy!
Outline of this knowledge block:
Introduction to EA analysis
The Multi-Attribute Prediction modeling language (class diagram)
Service availability
Enterprise income
Data accuracy
Application usage
The EA analysis formalism
and EA analysis according to others
If you have not read chapter 1.1, 1.2, and 2.1 in the book
IT Management with Enterprise Architecture
now is the time to do so before moving on.

The book is available on KTH Social.
If you have not watched the video
IT Management with Enterprise Architecture
now is the time to do so.
Download the following at www.ics.kth.se/EAAT
the EAAT object modeler
the MAP class diagram
At www.ics.kth.se/EAAT
read the EAAT manual. Read only about the Object Modeler. Don't bother about the class modeler
And watch the screen cast
Also, as a complement, to understand the how EA can be used for a decision making support; read chapter 1.4 in the book
IT mgmt w. EA
Chapter 3 in the book
IT mgmt w. EA
contains a "technical" description of the MAP class diagram. Skim read it to get an overview.

Each specific analysis will be detailed in the coming chapters.
Chapter 4 Application modifiability
Modeling tutorial
Using EAAT (the Object modeler) and the MAP class diagram follow the modifiability example in Chapter 4
For the modifiability interested, read:
“Architecture Analysis of Enterprise Systems Modifiability – Models, Analysis, and Validation” by Robert Lagerström et al., in the Journal of Systems and Software, vol. 83, no. 8, pp. 1387-1403, Aug. 2010.

“Architecture-level Modifiability Analysis (ALMA)” by PerOlof Bengtsson et al., in the Journal of Systems and Software, vol. 69, no. 1-2, pp. 129-147, Jan. 2004.
Data accuracy
Chapter 5 Data accuracy
Modeling tutorial
Using EAAT (the Object modeler) and the MAP class diagram follow the data accuracy example in Chapter 5
For the data accuracy interested, read:
"Data Accuracy Assessment using Enterprise Architecture" by Per Närman, in Enterprise Information Systems, vol. 5, no. 1, pp. 37-58, 2011.

"Data quality assessment" by Leo Pipino, Yang Lee, and Richard Wang, in Communications of the ACM, vol. 45, no. 4, pp. 211-218, 2002.
Service availability
Chapter 7 Service availability
Modeling tutorial
Using EAAT (the Object modeler) and the MAP class diagram follow the service availability example in
Chapter 7
For the service availability interested, read:
“Optimal IT Service Availability: Shorter Outages, or Fewer?” by Ulrik Franke, in IEEE Transactions on Network and Service Management, vol. 9, no. 1, March 2012.

“Automatic Generation of Service Availability Models” by Nikola Milanovic and Bratislav Milic, in IEEE Transactions on Service Computing, vol. 4, no. 1, January-March 2011.
Enterprise income
Chapter 9 Cost
Modeling tutorial
Chapter 11 Income
Using EAAT (the Object modeler) and the MAP class diagram follow the cost example in Chapter 9
For the cost interested, read:
"A Framework for Assessing the Cost of IT Investments" by Per Närman et al. in Proc. of the Portland International Conference on Management of Engineering & Technology (PICMET), 2009.

“Evaluating cost taxonomies for information systems management” by Zahir Irani et al., in European Journal of Operational Research, vol. 173, no. 3, pp. 1103-1122, Sept. 2006.
Read Chapter 8 Interoperability
Modeling tutorial
Using EAAT (the Object modeler) and the MAP class diagram follow the interoperability example in Chapter 8
For the interoperability interested, read:
“A Language for Interoperability Modeling and Prediction” by Johan Ullberg et al., in Computers in Industry, vol. 63, no. 8, pp. 766-774, Oct. 2012.

“Architectures for Enterprise Integration and Interoperability: Past, Present and Future” by David Chen et al., in Computers in Industry, vol. 59, no. 7, pp. 647-659, Sept. 2008.
Application usage
One of the more spectacular reference architectures is found in the "
Federal Enterprise Architecture Framework" (FEAF)
. Here you can find listings of all the "businesses" that the USA is involved in. Postal Services, Higher Education, Cultural and Historic Preservation, Crime Prevention, Health Care Administration to mention just a few... It can be noted that these are of course all extremely complex enterprises in them selves.
FEAF also include a Service component reference model and a Technical reference model with application services and IT-infrastructure components respectively.
More info on http://www.whitehouse.gov/omb/e-gov/fea and
Also you might want to revisit TOGAF (pdf available on Social or online at: http://pubs.opengroup.org/architecture/togaf91-doc/arch/) which includes a reference model of Technical IT-infrastructure components and solutions, section 43.5 page 506 and section 44.3 page 531.
EA models of enterprises
So, one thing is to talk about an enterprise and how it works and another thing is to get it down in an EA model.
But, this time you read it please think about the fact that neither of these examples have any analyses, or properties in ArchiMate, connected to them. This is a problem with state-of-the-art EA today. But with the content of this course you could add cutting edge knowledge to the enterprise you are (to start) working in!
As hinted several times in this material, the complexity of enterprises is the core challenge that this course is addressing. However, unless you have been heavily engaged in an enterprise it can be difficult to understand and envision this complexity.
In this block we have gathered material with the purpose of helping describing and explaining this complexity and how it can be captured in EA models. The material here is thus primarily to be seen as a source of inspiration for helping out with the course assignment. Go through it at a need-to-know-basis if you feel that you have got stuck with the question "how does an enterprise like mine really work...?".

In essence this material can be seen as a collection of reference architectures/models (cf. the modeling knowledge block) of enterprises in general.

The material is of course in no way complete. It can never be...
Reference business processes and solutions
In addition you might want to revisit:
Information systems reference technology
Web portal and services
Web portal and services
Enterprise Resource Planning (ERP)
Enterprises of the future
Hear what Gartner, one of the biggest Technology trend spotter companies, have to say about IoT:
Our friend from some previous videos also have some videos on IoT. But more hands-on examples:
For some examples on this, you can now return to the Qualiware example
or you can look at the various models of the ArchiSuracnce company in the ArchiMate specification Chapters 3, 4 and 5. (pdf available on Social)
The Multi-Attribute Prediction (MAP) modeling language
The project assignment states that you should model your enterprise in the Multi-Attribute Prediction (MAP) modeling language (/class diagram). Further you the assignment says you need to perform three types of analysis in MAP. MAP however contains eight different analysis mechanisms. These are all introduced here.

You should get a fair grip of all eight but you only need to dive into the details of the three you are choosing for the assignmnet.
So, unfortunately, it is not really that simple
Read Chapter 10 Utility
The learning activities of this knowledge module can be summarized as follows:
Skim Chapter 3 to get a grip of MAP.
Skim Chapters 4-10 to get a better grip of each part of MAP.
Choose three of the following; cost, availability, income, data accuracy, modifiability, interoperability, and application usage to focus on. Read these three more carefully.
Make sure you use EAAT and MAP and try all the examples.
The EA analysis formalism
So, how does the calculations really work in the tool...? Here's a module on how. But you don't need it for this course, so this part can be considered as extra reading for the interested.
Other approaches for EA analysis
The class models used in EAAT and especially the MAP class diagram you are using are based on a formalism called the Predictive, Probabilistic
Architecture Modeling Framework (P2AMF). It is this framework that enables the analysis.
For more information read:
P2AMF: Predictive, Probabilistic Architecture Modeling Framework, Pontus Johnson, Johan Ullberg, Markus Buschle, Ulrik Franke, and Khurram Shahzad, to appear in
Information Systems and e-Business Management
, 2014.

Available on KTH social
For the super interested reader there are alternative approaches. We have collected a set of papers presenting some:

Available on KTH social
Quantitative Analysis of Enterprise Architecture, Iacob and Henk Jonkers,
Interoperability of Enterprise Software and Applications
. Springer London, 2006. 239-252.
An AHP-based approach toward enterprise architecture analysis based on enterprise architecture quality attributes, Razavi et al.,
Knowledge and information systems
28.2 (2011): 449-472.
Analysis and Application Scenarios of Enterprise Architecture- An Exploratory Study, Winter et al.,
Journal of Enterprise Architecture
3.3 (2007): 33-43.
Enterprise Architecture Analysis with XML, de Boer et al.,
System Sciences
, 2005. HICSS'05. Proceedings of the 38th Annual Hawaii International Conference on. IEEE, 2005.
Exploring Intentional Modeling and Analysis for Enterprise Architecture, Yu et al.,
Enterprise Distributed Object Computing Conference Workshops
, 2006. EDOCW'06. 10th IEEE International. IEEE, 2006.
Supporting Landscape Dependent Evaluation of Enterprise Applications, Addicks and Steffen,
Multikonferenz Wirtschaftsinformatik
. 2008.
Chapter 6 Application usage
Modeling tutorial
Using EAAT (the Object modeler) and the MAP class diagram follow the application usage example in Chapter 6
For the application usage interested, read:
“Using Enterprise Architecture and Technology Adoption Models to Predict Application Usage” by Per Närman et al., in the Journal of Systems and Software, vol. 85, no. 8, pp. 1953-1967, 2012.
“Task-Technology Fit and Individual Performance” by Dale L. Goodhue and Ronald L. Thompson, in MIS Quarterly, vol. 19, no. 2, pp. 213-236, Jun. 1995.
TOGAF has already been mentioned several times in this course. It contains a method for how to plan and managed enterprise change projects. The method is called the Architecture Development Method (ADM) and is presented in part two (page 43) in the TOGAF document (available for download in Social). Transition planning is covered in ADM phases E (page 131) and F (page 141). As can be seen transition planning is fairly complex with many sub activites and dependencies to take into account. In assignment 2 of this course a transition plan is requested. In comparison to the full-fledged transition planning of TOGAF, the assignment transition plan is heavily simplified. In the assignment we are only asking for a transition plan between your as-is and to-be scenarios. Hence any activities related to project communication, project resource planning, organizational competence and capabilities, project governance, etc. are omitted in the assignment.
Thus the most relevant sections of TOGAF ADM for the assignment are the following:
Determine/confirm key corporate change attributes (see Section 13.4.1)
(This step is of course very key, but is already explicitly targeted in the MAP and EAAT EA models, so as a small step here it is somewhat superfluous)
Refine and validate dependencies (see Section 13.4.6)
Formulate Implementation and Migration Strategy (see Section 13.4.8)
Identify and group major work packages (see Section 13.4.9)
Identify Transition Architectures (see Section 13.4.10)
Create the Architecture Roadmap & Implementation and Migration Plan (see Section13.4.11)
Confirm Architecture Roadmap and update Architecture Definition Document (see Section 14.4.5)
Complete the Implementation and Migration Plan (see Section 14.4.6)
As templates for how transition plans could look see chapters 28.1, 28.2, 28.3 (pages 293-295) in TOGAF.
Additional and complementary material on architecture transition planning will be given in the lectures by Per Närman.

Knowledge block: EA frameworks
The Zachman framework
The generally considered first E framework is the Zachman framework. Very briefly, in the language of this course, the Zachman framework is a a categorization of different viewpoints. The framework does not have its own meta model but rather speak of different kinds of models and that they belong to one of the different categories in the framework. (The actual mapping of models to the categories to the categories my not always be as straight forward as might seem.) The original article on the framework, from 1987, is available on KTH Social.

More info is available at www.zachman.com
Here are two introductory videos. Viewing one might be enough.
And a comment on the framework from Zachamn himself:
Perhaps what most people think about when they hear the term EA are the various so called EA frameworks. These are different best practices of what EA is and how it should be executed.
A Note:
The frameworks do look different and contain different things so the joint label framework might be a bit confusing.
For the interested reader there is a paper available describing what the EA frameworks contain and cover. It is called the EA framework framework.
As brief introduction to frameworks read chapter 1.3 in the book IT managent with EA, available on Social. Further introductions to some EA frameworks are also provided here in the PEZ.
TOGAF has already been introduced in this course material. It is probably the most renowned EA framework. The core of TOGAF is the Architecture Development Method (ADM). But it also contains architecture building block reference models as well as suggestions on how EA work is to be governed and organized. Lately it has also adopted the ArchiMate as its formal metamodel.
Both the full TOGAF description and the ArchiMate specification is available on Social.
The TOGAF official homepage is: www.opengroup.org/togaf/
The Federal Enterprise Architecture
Also the Federal Enterprise Architecture Framework has previously been briefly introduced
More info on http://www.whitehouse.gov/omb/e-gov/fea
Military architecture frameworks
You should now be able to describe some reasons why (large) enterprises are complex an why this cause a challenge for business and IT-management
You should now be able to devise a simple transition plan for moving from an as-is architecture to a to-be architecture.
EA according to Microsoft:
EA in context:
Under this knowledge block we would like to highlight that EA work in theory and in practice differs. In this course we advocate EA analysis as an important (in practice often missing) factor for successful EA. Most of the videos in the course material as well as the EA frameworks describe how they thing successful EA is done.

In real life it is often not that easy, though...

We also would like to give you an understanding how mature EA normally is in enterprises today. Of course, the gap you will find compared to the content of this course is the gap that you will be able to contribute with after finishing the course.
During the course there will be a number of guest lectures that will provide insight on the topic of EA work in practice. We will also gather other testimonials on the subject here.
There is a whole community working enterprise architecture. Here are some suggestions on where you can look for more information and networking opportunities. So you can continue develop for a life time!
At the department of Industrial Information and Control Systems we try to keep track of former students through a LinkedIn group. So if you don't have a LinkedIn account create one (www.linkedin.com) and then apply to the group "Enterprise Architecture Education @ KTH"

In Sweden
The biggest EA network in Sweden is the LinkedIn group "NEA Nätverket för Enterprise-arkitektur i Sverige" that regularly also hold meetings. You can apply to become a memeber on LinkedIn

Another network is SWEAN - SWedish Enterprise Architecture Network. They also have a LinkedIn group but the network is primarily focused on arranging conferences.

A third group is "Sveriges IT-arkitekter - IASA Sweden", which is the Swedish section of the international organization IASA: The Global IT Architect Association (www.iasaglobal.org)

As you might have guessed, The Open Group (responsible for TOGAF) is one of the larger organizations developing EA. Membership is not personal however, but per company. They do organize conferences regularly, open also to non-members

There are also several EA groups on LinkedIn.
You should now be able to describe how EA work is supposed to fit into the larger business and IT management processes at enterprises.
You should now be able to name a few of the most prominent EA frameworks and roughly describe their content.
Now, let's get started!
Given the complicated enterprise, why is analysis needed and what good is it?

Have a look:
Ok, so hopefully you now agree that analysis seem to be important,


how is this done practically?
... and all the IT-systems (in modern enterprises)
And all the structure and processes to get it working....

Who's going to do what and make what decisions, and in what order...?
Well, actually this line seem to be slightly increasing over time... See:
The military in many countries have for a long time been working with EA (but they typically does not use the word Enterprise, for obvious reasons..) and have for instance developed extensive architecture frameworks

The British Ministry of Defence Architecture Framework (MODAF), the NATO Architecture Framework (NAF) and the US Department of Defense Architecture Framework (DODAF) have been developed, inspired by each other, to support defense planning and change management in the military context. Their scope includes all kinds of technology, not just information systems!

MODAF, NAF and DoDAF focus on metamodels and models, but say little about the process of creating models. Therefore, it has been proposed that they ought to be used together with the more process-centric TOGAF. Read the abstact here:

The British MODAF site has a lot of good material on the viewpoint, views and use-cases of the framework. Go ahead and have a look:

Go ahead and have a look at this DoDAF tutorial, but don't spend too much time on it!
This PEZ is a container for the content of the course. In here you find all the information and pointers to everything that constitutes the course material (except for the lectures/seminars). In addition to the course content there is of course administrative things you need to be up to date with.

All additional information about the course you find on course site at KTH Social:

In essence there are three documents you must read to get the full picture of the course:
The course syllabus
The assignment description
The schedule
These are available under https://www.kth.se/social/course/EH2770/page/course-admin-documents/
In brief these documents are saying
The assignment
You have just been hired as the chief IT architect at a large enterprise. The enterprise’s Chief Information Officer (CIO) (the role in charge of all the IT at the enterprise), who is also quite new in office, is giving you the assignment to bring order to the chaotic information system portfolio.

You will use enterprise architecture for planning and presenting this enterprise transformation strategy.
You will be working in groups of four with the assignment.
Course activities
The main work in this course will be spent by studying material by your self, or in groups, and to work on the assignment.

In addition to these studies, the course contains:
guest lectures
(to give you input on how EA works in reality)
tutoring sessions
(where yo can ask questions to the teachers about things that you find challenging or unclear related to your assignments)
requested lectures lectures
(if there are topics that are unclear from studying the material in this PEZ)
a feedback seminar
(you will hand in a draft of the assignment which will be read and commented by the other students in the course as well as the teachers)
an oral presentation of the final assignment report
The course is graded on the scale A-F (and Fx). The grading is based on:

attendance at guest lectures and active participation in seminar
the quality of the final report of the assignment
the performance of the oral presentation
(and potentially the performance on an oral exam)
What is the value of the course for you...?
Enterprise architecture is a fairly new area. On the downside this means that the knowledge in the field is not as mature and rigid as compared to other fields. But, on the upside, this means that you will be able to contribute with your new gained knowledge from this course in practice faster.

In fact, after you finished this course you will have a unique knowledge on some aspects of enterprise architecture that many of the people working in the field don't have.
then what...?

Already at the end of the course you can contribute to industry by practicing your new skills

But of course, there is always more to learn for the interested

More courses and MSc thesis projects at KTH
Continue by deepening and broadening your knowledge by:
taking our advanced course EH2781 (in this course you will do a case study on a real enterprise that we provide
doing a Master thesis project with us
Life-long learning
Good luck in your future career!
The challenge of IT management - enterprises are inherently complicated and they have legacy of people, processes and IT-systems that cannot be changed without significant effort.
please recap the following:
Have a look:
As you heard at the end of the previous presentation there is a tool available for you to do analysis.

Now go and download it!
The Enterprise Architecture Analysis Tool (EAAT)
You should now be able to use the EAAT tool and make a simple analysis.
EA success stories
EA failure stories



Here is a compilation of news clips describing the challanges of IT managment. Use it as inspiration!







And some in Swedish..




Podcast on IT in the health sector

Legacy IT

You are close to becoming an expert! - Valuable to industry.
You have now gone through the four main knowledge blocks of the course. The remaining blocks are not as elaborate as the previous ones, but they are neither a necessity to just pass the course. They are there to broadening your perspectives and to align your knowledge with the EA community in general.

Of course, we encourage you to have a look at it.
In the book there is a chapter on how to trade different properties against each other. This is of course important; you cant have everything, and certainly not for free... In this course we wont go into the formalization of this trade-off, but please read it if you are interested.
So, unfortunately, it is not really that simple
So, Enterprise Architecture maps...
What do they look like?
How can they be used?
That is what this course is about.
EA, EA on my computer screen, tell me how to make a well-performing enterprise..!
Full transcript