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.


Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks


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

Mathias Ekstedt

on 17 February 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of EH2770-2015-v1.0

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.)

Also an extensive part of the learning will be from working hands on withthe assignmnet and discussing it in the project group. Group work and discussions are learning, not overhead!
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, marked with different icons:

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

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. In this course we will use a slightly modified, and extended metamodel. We call it the Multi-Attribute Prediction (MAP) meta model.
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 course 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 KTH Social).
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 set-up
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 contain 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 the 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 (or course web)
the EAAT object modeler
the MAP class diagram
At www.ics.kth.se/EAAT (or course web)
Download/read chapter 4 in the EAAT manual. (Note! The manual is not up to date with the latest version of EAAT (since it is continuously updated. Thus some things may have changed. The major part of the manual is still correct. In case of confusion, ask!)

Watch the MAP object modeling screen cast. (Note! This screen cast is using an old version of MAP in the example. The general modeling and analysis approach is still the same.)
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
Overview of Multi-Attribute Prediction (MAP) Modeling Language
Application Modifiability
coupling and size
Download and study viewpoint material from course web - both on coupling and on size.
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
Download and study viewpoint material from course web
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.
Download and study viewpoint material from course web
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.
Download and study viewpoint material from course web
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.
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:
You can also 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)
An example
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 the assignment says you need to perform three types of analysis in MAP. MAP however contains six different analysis mechanisms. These are all introduced here.

You should get a fair grip of all six but you only need to dive into the details of the three you are choosing for the assignment.
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.
Download and study viewpoint material from course web
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!
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/

The main part of the course material is contained in
this PEZ.
Some additional information (e.g. guest lecture slides) are available on course site at KTH Social: https://www.kth.se/social/course/EH2770/

During the course also additional administrative information and Q&A will be communicated via the
News Feed
at KTH Social.
3. 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.
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.
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..!
Essentially cheating has to do with not complying with the rule related to the examination. On exams you are only allowed to bring certain aids such as a calculator or a set of specific formulae. Etc.
For the context of this course this is translated to that you may only sign up on mandatory lectures if you are actually there - the whole time -, and that the content in the in the assignment report is actually yours and not copied from someone else.
If you do copy information into the report it must be properly referenced.

Now, sometimes there are arguments for why some "small cheating" (like missing the first ten minutes of a lecture or borrowing someone elses figure without referencing) still would be OK. Here are some longer arguments why this is not OK:

1) Cheating at examination is not allowed. No matter what the subject is or how stupid, silly, or irrelevant you feel that the examination is. This is a KTH rule and it has nothing to do with this course at all. So while at KTH you (and we) need to live with it. (It is the same as laws in the society; you might personally disapprove to a law but you have to live by it anyways.)
2) What is the relevance of the guest lectures? We think that there are several benefits guest lectures. The main reason why we have them however is because we want to teach what we could call “EA in practice”. How do professionals do EA and what do they think about EA in general? This is an important knowledge for you to have if you are going to work in the field. It is a crash course in EA culture so you are at least somewhat prepared to “talk the talk” with the EA community. We believe that this topic is important to complement theoretical knowledge. For this reason, we have put this learning module in the course.
3) Your learning process. We are fond believers of that students should take ownership and responsibility over their learning and adapt it to the way that they feel is most suitable to their individual preferences. This is the reason why we have developed this PEZ and minimized “theoretical” lectures. We want to maximize your freedom and responsibility.
For the “EA in practice” learning module the freedom of the learning process is not as large as the rest of the course. (But on the other hand, you can choose examination form.) Here you can choose to either to attend the lectures or to hand in an (or potentially several) essay(s). Attending lectures is in a way a sloppy examination because we do not thoroughly check that you actually learned the content. But we felt that it would be to overambitious to also have an exam or a separate report on the lectures. We believe that attending lectures take less time and that you learn more from them than writing essays on other material. Nevertheless, the choice is up to you!
4) Other dimensions to guest lectures. We also see other benefits with guest lectures than only filling “EA in practice” purpose. It is our experience that most students are very eager to get better contact with future potential employers. And even if five companies cannot host all students in the end of course we think that listening to them could inspire you on the subject and that you may get ideas on how and on what subjects you would like to dig deeper into. Maybe you get an idea of a Master thesis topic, e.g.? We also believe that the lectures provide some input to the assignment in this course, so also from that point of view it is interesting to have them (even though this is thus not the primary reason).
A concrete example of how they work at an internet-based grocery store:
Course goals
EA skills
Upon completion of this course the participants should be able to:
• With examples describe and explain the complexity in business operations and its IT support in large enterprises
• Produce understandable and realistic enterprise architecture models of enterprises in a predefined modeling language.
• Use enterprise architecture models (created in a predefined modeling language) to analyze the quality of different scenarios of business and IT-systems solutions.
• Create simplified enterprise transformation plans for moving from a current situation to a future desirable state.

EA in practice
- contextual EA understanding
Upon completion of this course the participants should:
Have a basic understanding of how enterprise architecture is used in practice in organizations today.
Course activities
This PEZ with all its content.
The main course activity.
Assignment work
Written report and oral presentation

Guest lectures
Given by EA practitioners from industry

Tutoring sessions
Each group present their questions for all (interested) participants. Teachers answer.
Peer review seminars
Commenting on report drafts.
Two occasions.
Given by KTH teachers. Introduce the material.
Bring two printed copies of your own group’s report to the seminars
Teachers will act as learning support at all occasions except when grading the student work.
In order to keep the two teacher roles clearly separated no tutoring/learning support will be offered the last week before the final assignment hand-in.
Guest lectures
80% attendance mandatory
write a review on an article for missed lectures
write a review an interview with EA practitioner for missed lectures
Assignment work
Written report - mandatory
Oral presentation - mandatory

(Oral examination - only in case of group members disagreeing on member's contribution to assignment work)
Graded A-F/Fx
Graded Pass/Fail
i.e. your means for learning...
A note on plagiarism and cheating...
We hate to cover this boring and spirit-draining subject, but every now and then the topic is brought up by incidents, so here are some comments on it. In short, we will not accept plagiarism or cheating of any kind. If you want to hear why you can continue reading, but promise that it won't let it drain your spirit...
Industrial mentors
Book time with an EA practitioner to discuss your questions and ideas (or whatever's on your mind..)
1. Sources of Information
2. Course Design
4. How to approach the course
Advice from previous students
At the previous course evaluation we asked "What would you like to say, or which advice would you like to give, to students taking the course next year?" These are some answers:
Start early reading all the material given and then also start early on the project. Takes time to understand everything regarding the modeling tool and language.
It would do you good to finish up the course materials first before even trying to tackle the projects. Try to get the overall idea on how EAAT works.
Start early, ask questions and make sure to get a good mood going in the group. If you start off with bad communications, you won't be able to finish on time with a satisfactory result.
Use company that is well know to all group members.
Make sure that you choose a company that you can find enough information about so you don't have to "guess" how everything works.
Start taking things seriously from the beginning to model a company is no easy task!!
Try to understand the difficulties with the tool at the earliest. Use very small models.
I would recommend these persons to read first an introduction about ArchiMate. Then it is easier to understand MAP.
To figure out as fast as possible what parts of their business they are going to model and be specific and not vague. Don't try to model everything, model a few things in general to show the complexity of the business but go deep in a specific part or process of the business. But figure it out quickly. Once you have done that, then things get in order and you have a better idea on how to proceed for the calculations, the to-be models and the report.
Start with the software and the book to understand how to use.
Read the course book and make use of the seminars
Start early
To be prepared like all other courses. If they are interested in the topic it will go just fine.
Students with special needs
If you are in need of adapted examination due to a diagnosis, contact the course responsibles and the coordinators at the "Funka" office: http://www.kth.se/en/student/studentliv/funktionsnedsattning/kontakta-samordnaren-1.39745
Forming of groups
You will form the groups by your self. When forming groups think about synchronizing your ambitions in the course. Please feel free to use the news feed on Social to form groups. When signing up groups (see course memo for how-to) you also need to specify what kind of enterprise you will be working with in the assignment.

In case of troubles in the group
Working in groups is a way of study and learn. It also a very common way of working in workplaces. Thus we encourage you to take the opportunity to take advantage of this situation.
even if intentions are good and ambitions are in sync, disagreements may arise... If they do, and you feel that you will not be able to sort them out in the group, please
contact the course teachers
. If the disagreement is related to course content, we can clarify things. If the disagreement is about how you work we can try to help resolve the situation. In worst case we can agree on a solution for splitting or re-arranging the the group.
It is important that you are not failed in the course due to problems like this!
Here is a webinar on how EA has been used for restructuring business processes at a UK university
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

EA Tools
Goal: You should be aware of that there exists many different tools to support enterprise architects.
Enterprise Architecture tools
Doing all the EA modeling by hand gets tedious when you have big models, so in practice dedicated tools are needed. At the same time, in practice perhaps the most common EA tool is still Powerpoint... But most organizations working seriously with EA do also employ an EA tool (or several..)

There exist a great number of EA modeling tools on the market. To mention just a few:
-Qualiware (http://www.qualiware.com/products/the_modeling_platform/qualiware_enterprise_architecture)
-Troux (http://www.troux.com/enterprise-architecture/products
-Sparx (http://www.sparxsystems.com/products/ea/)
-IBM (http://www-03.ibm.com/software/products/en/ratisystarch)
-Free and thus perhaps most easily accessible; Archi, supporting only the ArchiMate language (http://www.archimatetool.com)

This course will no go into details about tools as such, so the list above is just for general information and inspiration.

However, in this course we will also use a specific tool called KTH Eneterprise Architecture Analysis Tool (EAAT). As oppose to the tools above the EAAT is not a commercial tool but a research prototype. The reason for using EAAT is that it is specifically design to do analyses. The commercially available tools only do modeling, not analysis. It is a bit like if CAD tools for mechanical design could only do design but no simulation of how much stress, preasure, heat, etc. the design can cope with before it brakes. Understanding how to conduct analyses of EA models is also the key competitive edge you will get after finishing the course. More about the EAAT later in this PEZ.
In this course you will do analyses according to the scheme presented in this video. However the exact analysis (EA language) shown in the video is not what you will be working with
You will work with an updated version of the presented EA language
. So, focus on the approach and disregard the exact details of attributes and attribute values.
Note! The exact layout of the web page is subject to change
In the following example a MAP model has been made of a fictitious company called ArchiMetal. the ArchiMetal case is described in an Open Group document available at the course web as well as at:
At the course web there is also a MAP model (ArchiMetalv1.0.iEaat) of (a smaller part of) this document.

This example was made to support the following purposes:
- Help you get started with MAP modeling in EAAT
- Illustrate that MAP and ArchiMate are similar but not identical

More examples...
There exist many examples of EA models that can serve as inspiration for the course assignment. Some examples:
The already introduced QualiCar:
The Open Group ArchiSurance case:
Iteraplan demo:
However, none of these examples have corresponding MAP models available...
Note! The exact layout of the web page is subject to change
In MAP, application modifiability have been subdivided into two separate dimensions; application coupling and application size.
Utility is, in comparison to the other attributes in MAP, somewhat a horse of a different color. Utility concerns how well the other properties meets the expectations or needs of the enterprise. Thus it enables trade-off support for the other properties
Is that all?
Of course, we can imagine an great number of properties to analyze for enterprises. Interoperability, application performance, security, reliability, business efficiency, business effectiveness, revenue, to mention few. Many of these properties also impact each other.

In MAP we have only implemented a few. Also the way these attributes are calculated are heaviliy simplified and many impacting factors have been disregarded. But, the point we try to make is that EA models should and can be analyzed in a structured way. In the future, as an enterprise architect you will hopefully devise your own analysis mechanisms of various kinds, formalized or not...
Another example
The following 10 videos show screen captures of an example om how to mode and analyze with MAP.
Full transcript