Using an IT Laboratory for Training IT Architects
Lina Casas, Mario S
´
anchez and Jorge Villalobos
Systems and Computing Engineering Department, Universidad de los Andes, Bogot
´
a, Colombia
Keywords:
Project Based Learning, IT Architecture, Reality Simulated Cases.
Abstract:
Information Technology Architecture (ITA) has been known for its importance in the alignment of the busi-
ness’s needs and its technological strategies. As the companies have become more complex and the market
more competitive, ITA has gained more significance and the demand for IT architects has strongly increased
around the world. Nonetheless, the offer of qualified architects is not growing as fast. This is because a qua-
lified IT architect is not easy to find as he or she has to possess many hard and soft skills. It is not a surprise
then, that the time frame required for a professional to become an experienced IT architect is too long, the
necessary experience is difficult to acquire and the skills are difficult to develop. This paper proposes a way to
help students and professionals obtain these elements through a project based approach supported by different
reality simulated enterprise cases. These cases compose what we call an IT Laboratory.
1 INTRODUCTION
IT Architecture is the discipline that focuses on de-
signing and delivering valuable technology strategies
to companies (Marks, 2016). It differs from Enteprise
Architecture because IT Architecture not only com-
prises the design and planning of the IT solution that
complies with the business’s needs, but also includes
the implementation of that solution. In recent years,
IT Architecture has gained considerable importance
due to its high impact in organizations. IT Architects
are in high demand around the world but, as it often
happens in IT related jobs, there are not enough quali-
fied professionals for the role. With the goal of produ-
cing a profile which can deal with the market challen-
ges, many organizations and institutions offer training
programs for IT architects. Those programs vary from
seminars or short courses to extensive and long ones.
Programs such as The Open Group TOGAF Certifi-
cation Program (Scherer and Wimmer, 2011), Certi-
fied IT Architect (CITA) (Clements, 2010), and IEEE
Computer Society’s Certified Software Development
Professional Program(IEEE, 2005) are quite popular
and aim to produce highly adaptable professionals,
with deep industry comprehension, high business in-
sight, and profound technology knowledge.
However educating architects is a difficult task, as
the real world comes with a lot of different contexts,
challenges, risks, and uncertainty that they will have
to face. Thus, in order for students to gain the in-
sight and expertise for a real IT architecture project,
they need to obtain not only theorical knowledge but
practical experience as well. One alternative is practi-
sing in a real enterprise project. However, this would
be too risky for the enterprise, take too long, and will
only let the students practice on some very specific
problems.
With the purpose of offering a more complete trai-
ning for professionals who want to become IT archi-
tects, we propose the use of an IT laboratory which
consists of a set of simulation scenarios regarding
fictional organizations. These scenarios resemble a
complete organization with strategic and operational
components and real technology implementation sup-
porting it. Furthermore, the scenarios illustrate diffe-
rent industries in order to make students learn about
different verticals. They also recreate the complexity
and imperfection of a real company. Taking those sce-
narios as a base, the students can have an environment
to practice, reinforce, and integrate all the concepts
concerning analysis, design, and implementation of
IT architectures.
An IT laboratory is used on several academic pro-
jects focusing on different phases of IT architecture
projects. The focus in each phase is determined ac-
cording to the course and program level, and the set of
skills the students should acquire or improve. At the
end of the projects, the achievement of those compe-
108
Casas, L., Sánchez, M. and Villalobos, J.
Using an IT Laboratory for Training IT Architects.
DOI: 10.5220/0006319901080119
In Proceedings of the 9th International Conference on Computer Supported Education (CSEDU 2017) - Volume 1, pages 108-119
ISBN: 978-989-758-239-4
Copyright © 2017 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
tences can be evaluated. With the purpose of giving
the students interesting projects to work on, the ob-
jective and scope of the projects should be carefully
defined and the evaluation schemes adjusted and vali-
dated.
The paper is structured as follows. Section II des-
cribes what an IT architecture project is. Section III
explains what a project based approach is. Section
IV details the proposed definition of an IT laboratory
used to train students and professionals. Section V
shows a case study of the IT laboratory use and eva-
luation in an academic program. Finally, Section VI
presents the conclusions regarding the benefits of the
IT laboratory.
2 IT ARCHITECTURE PROJECTS
An IT Architecture Project is typically distributed in
non-linear phases or cycles. Each cycle has an inter-
nal set of activities and its purpose is to obtain a pro-
duct or deliverable once it is finished. Also, at the end
of each cycle there a stakeholder’s validation in order
to get feedback and do the necessary adjustments.
We created a model with the common cycles in an
IT architecture project process and its activities. This
model, as shown in Figure 1, is based on different
frameworks and methodologies such as (Team Soft-
ware Process) TSP (Humphrey et al., 2010), (Rational
Unified Process) RUP (Shuja and Krebs, 2007) and
TOGAF’s ADM (Harrison, 2011). The proposed pro-
cess includes activities that go from planning to exe-
cuting and deploying the solution, distributed through
six major phases: (PP1) Planning, (PP2) Information
Gathering, (PP3) Analysis, (PP4) Design, (PP5) Ro-
admap, and (PP6) Implementation. Each phase and
its deliverables (such a document with the models or
a code part) composes a portion of the final product
to be delivered to the final users. This incremental ap-
proach assures quality and relialibility of the product
through continuous refining and adjustment. Because
of this, in a typical IT Architecture project it is not
strange to find redesign steps in subsequent phases.
It is important to note that some frameworks and
methodologies do not consider the final phase (PP6)
Implementation as a part of an IT Architecture Pro-
cess but more as a part of the Development Process.
Nonetheless, we firmly believe that an IT Architec-
ture is not complete until the final product is relea-
sed. Moreover, the IT architect must be involved in
all the phases even if the final step is performed by
a development team. The reason for that is twofold:
the architect’s insight is truly important on the deve-
lopment tasks and a qualified architect must have pro-
found knowledge of the development stages in order
to get the expertise to execute ITA projects correctly.
In order to train architects that can adequately per-
form an ITA project, they should have many skills
concerning technology knowledge and personal abili-
ties. To define these set of skills we performed a lite-
rature review and enhanced them through surveys and
interviews with instructors and IT experts, as recom-
mended by Kalampokis (Kalampokis et al., 2012). In
the review we took into account the different roles of
an IT architect and the competences each role needs to
have in order to sucesfully contribute to an ITA pro-
ject according to TOGAF (The Open Group, 2011),
IASA (International Association for Software Archi-
tects, 2016), TSP (Humphrey et al., 2010), and RUP
(Shuja and Krebs, 2007). We also included the Accre-
ditation Board for Engineering and Technology (Fel-
der and Brent, 2003) which defines a series of abili-
ties, called student outcomes, that represent what stu-
dents from any discipline are expected to know and
be able to do. Making a match between the consul-
ted sources and the expert’s validation, the list was
completed and edited. The list is presented on table
1. Using this list as a baseline, we calculated skills
required in every phase of an architectural project, as
shown in Figure 2.
3 PROJECT BASED LEARNING
Project Based Learning (PBL) is a pedagogical ap-
proach which aims to confront the students with pro-
blems and challenges similar to those found in the real
world. It is mainly based on giving the students the
opportunity to not only memorize concepts but also
put them in practice on different projects and activi-
ties. PBL integrates knowing and doing. Students
acquire knowledge and learn elements of the core
curriculum, but also apply what they know to solve
authentic problems and produce results that matter
(Markham, 2011). More information about PBL work
scheme and advantages can be found on (McCormick,
2008) and (Wankel, 2005), respectively.
Additionally, there has been research on the use
of IT in the PBL approach. The use of IT technolo-
gies can be extremely helpful when defining projects
because they can simulate real environments where
students can practice. This is the case of Hypercase,
an interactive system’s analysis and design simulation
tool which is used on different courses and books.
More about Hypercase can be consulted on (Kendall
and Kendall, 2014).
In order to correctly apply the project based appro-
ach, students must be confronted with reality simula-
Using an IT Laboratory for Training IT Architects
109
PP1 - Planning
PP2 - Information
Gathering
PP3 - Analysis
PP4 - Design
PP5 - Roadmap
PP6 - Implementation
●
Perform interviews
●
Analyze organization
documents
●
Identify stakeholders
and concerns
●
Identify data, applications
and infrastructure
portfolio
●
Define objectives
●
Define scope
●
Define methodology
●
Define team
●
Identify possible risks
●
Describe business
models
●
Describe conceptual
●
models
●
Describe application
models
●
Describe services
blueprint and portfolio
●
Define infrastructure
models
●
Propose changes in
business models
●
Propose changes in
●
conceptual models
●
Propose changes in
application models
●
Propose changes in
services blueprint and
portfolio
●
Propose changes in
infrastructure models
●
Perform gap analysis
between what was
described and proposed
●
Identify projects to close
gap
●
Prioritize projects
●
Identify transition
architectures
●
Determine development
strategy
●
Assign team roles
●
Estimate schedules
and costs
●
Develop/Tailor
applications (apps)
●
Test apps services
●
Deploy apps services
●
Define service level
agreements
●
Train potential users
Figure 1: IT architecture project process.
PP1
PP2
PP3
PP4
PP5
PP6
SK1
x
X
X
X
SK2
X
X
SK3
X
X
X
SK4
x
x
x
X
SK5
x
x
SK6
x
x
X
x
X
SK7
x
X
SK8
x
x
X
SK9
x
X
x
X
SK10
X
SK11
X
x
SK12
X
SK13
X
SK14
x
SK15
X
x
X
SK16
x
X
SK17
X
x
X
X
SK18
X
SK19
X
x
X
SK20
x
X
X
SK21
X
SK22
X
SK23
X
Total
7
8
6
13
12
8
Figure 2: Skills required in each phase.
ted situations that help them gain the necessary ex-
pertise to act in each case. To be truly useful, the case
studies must also meet some requirements. First, the
cases must be coherent and resemble a real situation:
they have to make sense and provide correct input for
the students to practice with. Second, the cases have
to present a complex context to the students. If they
are confronted with an ideal and simplified situation
they are not going to be ready to face a difficult one.
Finally, they have to evolve in time as real enterprises
do in response to regulations, market and technology
changes.
In order to provide cases that cover all the require-
ments cited above, we created the IT Laboratory as a
set of reality simulated scenarios in different business
verticals. This laboratory has been used for six years
as the main tool in more than ten graduate and under-
graduate courses and for hundreds of students. The
next two sections present the processes for creating
and using scenarios in the laboratory.
4 IT LABORATORY
The IT Laboratory is based on a solid and flexi-
ble infrastructure capable of supporting a set of vir-
tual companies belonging to different business verti-
cals, which pose architectural challenges that students
must understand, analyse, and solve. The laboratory
was created with the purpose of giving the students
of different IT programs the opportunity to interact
with reality simulated cases in a controlled environ-
ment. In this environment, training is complemen-
ted from the experience, in addition to the theoretical
knowledge acquired. This approach can be used in
undergraduate, graduate or business education, chan-
ging the size and difficulty of the assignments accor-
dingly. These virtual companies or cases are called
CSEDU 2017 - 9th International Conference on Computer Supported Education
110
Table 1: Skills required by an IT architect.
ID SKILL
SK1 Analyze and understand problems,
requirements and constraints
SK2 Design, document and justify
proposed solutions
SK3 Build, implement, operate
and manage designs
SK4 Manage IT projects
SK5 Work in multidisciplinary teams
SK6 Work with other IT roles
SK7 Recommend implementation projects
prioritization
SK8 Guarantee quality in IT
SK9 Lead work teams
SK10 Communicate business and IT concepts
SK11 Give value to business through IT
SK12 Understand the organizations business
SK13 Align business and IT
SK14 Define business projects scope
SK15 Manage software
SK16 Design software
SK17 Develop business strategies
SK18 Define the IT architecture
SK19 Optimize business capabilities
SK20 Manage the integration and reuse of
existing elements of the EA
SK21 Design solution architecture
SK22 Integrate technologies
SK23 Give recommendations regarding to the
appropriate solutions for specific problems
scenarios and they are divided in two groups: con-
ceptual scenarios and operational scenarios.
Conceptual scenarios are composed by business,
information, application, and technology models but
without a real implementation to simulate its opera-
tion. Operational scenarios have a real technology
solution in which students can work and implement
IT architecture projects. An operational scenario im-
plementation consists on a set of virtual servers sup-
porting enterprise components like Enterprise Service
Bus (ESB), Enterprise Resource Planning (ERP), Cu-
stomer Relationship Management (CRM), and Busi-
ness Process Management Suites (BPMS) , as well
as other custom made software applications. The un-
derlying infrastructure recreates the software and har-
dware capabilities of a big or medium company. This
infrastructure is composed by virtual machines with
varying technology capabilities. Those virtual machi-
nes are hosted in a medium available datacenter.
Currently, the IT laboratory has more than thirty
virtual machines, 1.5 TB of storage, 228 GB of me-
Front-end
<<device>>
OS:Windows
Server2003
Weblogic
Server
OSB
Oracle XE
<<device>>
OS:Windows Server2003
InternetInformation
Services
FTPServer
Integrated
WeblogicServe
r
Oracle
WebCenter
Oracle XE
WeblogicServer
EmbeddedLDAP
Back-end
<<device>>
OS:Windows
Server2003
Weblogic Server
OracleBPM
Oracle XE
<<device>>
OS:Windows Server2003
Internet
Information
Services
FTP
Server
Integrated
WeblogicServer
MySQL
Apps
OracleBAM
<<device>>
OS:Windows
Server2003
Weblogic Server
OSB
Oracle XE
<<device>>
OS:Windows
Server2003
Glassfish Server
MySQL
Metadata
Manager
DNS
LAN
Figure 3: Scenario deployment model.
mory and 2.8 GHz of processing power. It also has
web pages describing the scenarios and has served
as an experimentation environment for more than ten
different students cohorts in three different programs.
An model describing the deployment of one particular
scenario is shown in Figure 3. This model shows the
supporting servers for an IT implementation, divided
into front-end and back-end. The first group repre-
sents the servers’s hosting components that directly
accesed by the users. The second one represents all
the servers in charge of different functions and ope-
rations that do not have direct contact with the users.
Additionally, there are components that do not belong
on either group, since they are servers responsible for
hosting auxiliary services such as load balancing and
redirection.
Nowadays, our laboratory has 11 conceptual sce-
narios and 3 operational scenarios in diverse indus-
tries and with different contexts. Figure 4 shows the
distribution of the different conceptual and operatio-
nal scenarios. As it was previously exposed, there is
a clear difference between the components in concep-
tual and operational scenarios. That difference im-
pacts the type of students that use the scenario and
likewise the projects they have to face. Conceptual
scenarios do have an architectural documentation the
undergraduate students can review, use and change in
order to develop the first five phases of an IT architec-
ture project. However, because of the courses’s level
and objective, they do not implement or modify any
solution. On the other hand, graduate students can use
the operational scenarios to face complex and com-
plete IT projects in order to complement their educa-
tion.
Using an IT Laboratory for Training IT Architects
111
PP1 PP2 PP3 PP4 PP5 PP6
Conceptual
Scenarios
Operational
Scenarios
Undergraduate students
Graduate students
Engineering and
Construction
Real estate
Telecommunications
Professional services
Healthcare
Media and
Entertainment
Software Development
Retail
Financial services
Manufacturing
Current
scenarios
Scenario
type
Student type
IT Architecture Project Phase
Scenario
components
Architectural
documentation
Architectural
documentation
Information
systems
implementation
Figure 4: IT Laboratory Distribution.
4.1 Operational Scenarios
An operational scenario is defined as a company in a
specific industry vertical. It is developed by a group
of scenario builders with the help of industry ex-
perts who help by gathering information and vali-
dating some of the subsequent steps. A scenario is
mainly composed by two elements: an IT Architec-
ture documentation and an IT solution. The first one
consists mainly on the artifacts (models and docu-
mentation) related to the four IT architecture domains
(business, information, application and technology).
The IT solution refers to the software and hardware
components needed to support the defined ITA. The
process for creating an operational scenario follows a
specific methodology which is showed in Figure 5 and
explained step by step in the following subsections.
4.1.1 Context
Once the industry for the scenario is selected, the
first step consists in acquiring background informa-
tion about the industry. Scenario builders thus rese-
arch the business vertical, and in particular, they look
for industry’s benchmarks which consists of key in-
dicators, drivers, and comparisons of how companies
perform relative to their competitors. This informa-
tion gives them solid foundation about the vertical and
the most important indicators, motivators and challen-
ges a company on that industry has to endure. Moreo-
ver, they look for similar organizations to learn more
about its typical operation, resources and customers.
Lastly, they have interviews with industry experts. All
this information helps scenario builders get a deeper
understanding about the typical processes, infrastruc-
ture and day to day operation of that industry.
4.1.2 High-level Design
With a more profound knowledge about the business
vertical, scenario builders start a high level design of
the four domains of IT architecture: Business Archi-
tecture, Information Architecture, Application Archi-
tecture, and Infrastructure Architecture.
In each domain, they design a number of critical
models. After they are completed, there is a check-
point with industry experts to validate if the archi-
tects work is correct and accurate. The typical step
after the validation is adjusting and refining the mo-
dels, and assuring compliance with the prime require-
ment of a utile case: coherence. Then, scenario buil-
ders perform a Strengths, Weaknesses, Opportunities,
Threats (SWOT) Analysis in order to identify future
transformation-drivers for the company.
During these steps, scenario builders also have to
assure that the design shows a high complexity le-
vel. Thus, the scenarios require big business models,
many bussiness processes, and a great number of ap-
plications, among others. Furthermore, the simulated
company may have to be imperfect as any real com-
pany is, presenting problems and inefficiencies. This
makes the scenario compliant with the second requi-
rement of useful case studies.
4.1.3 Detailed Design
Taking the high level design as a base, scenario buil-
ders can start constructing more specific architectu-
res: process architectures and solution architectures.
The first one, starts with the previous bussiness mo-
dels and delves into the macro-processes of the value
chain. For each macroprocess, scenario builders de-
sign and model the processes and subprocesses that
CSEDU 2017 - 9th International Conference on Computer Supported Education
112
Figure 5: Scenario Creation Methodology.
support or facilitate the company’s operation. The
second one, accommodates the application, informa-
tion, and technology layers of the company inclu-
ding the service portfolio and the integration blue-
print. The services portfolio organizes all the servi-
ces the IT solution has to offer in order to support the
bussiness and the integration blueprint shows shows
the interactions and the nature of these interactions in
between the IT solution components.
4.1.4 Build
With all the previous definitions, scenario builders
start building code for each software component, ex-
pose the services, test them and, once finished, in-
stall and deploy the components on the infrastructure
acquired for the scenario. When scenarios are com-
pleted they become useful for different courses and
and following their completion the Academic Projects
phase showed in Figure 5 begins. This phase is expan-
ded in Figure 6.
4.1.5 Initiative Definition
We define an initiative as a business transformation
driver the student must materialize into real changes
in the company business and IT components through
a project. Choosing the initiatives is a complex task
because they have to be consistent with the company’s
environment and assure that during their development
students integrate the knowledge acquired on theore-
tical classes and develop correct skills. Therefore, the
instructor has to do several activities before selecting
a good initiative.
In order to identify possible initiatives, the instruc-
tor uses the SWOT analysis and looks for possible
actions to exploit an opportunity, eliminate a weak-
ness or mitigate the impact of a threat. Moreover, the
instructor analyzes the company as a whole, taking
into account external and internal forces that may af-
fect its operation. This leads to other possible initiati-
ves. Once the possible initiatives are written down, it
is necessary to perform an evaluation to prioritize and
select the best ones. For the evaluation there are two
main criteria: the architectural effort, including skills
involved, and the estimated time to develop the initi-
ative. For the former one, the definition of the skills
required in each IT project phase that was introduced
in section 2 is used.
The instructor estimates the effort points by me-
asuring how much dedication each candidate initia-
tive requires in the different phases of an architectu-
Using an IT Laboratory for Training IT Architects
113
Implement
Initiative
Definition
6.11 Test and
Deploy
Services
6.10 Develop
/Tailor
Applications
Modify Business Architecture
6.1 Modify
Business
Models
Modify Applications Architecture
6.4 Modify
IT
Capabilities
6.5 Modify
Software
Components
Modify Information Architecture
6.2 Modify
Conceptual
Model
Modify Process Architecture
Modify Solution Architecture
6.7 Modify
Processes
6.8 Modify
Services
Portfolio
6.9 Modify
Services
Blueprint
6.6 Modify
Macro-
Processes
Analysis
5.2 Estimate
Architectural
Effort
Evaluation Adjustment
Selection
5.6 Select
Initiative
Project
Development
5
6
Process
Integration
7
Academic Projects
Instructor
Student
5.1 Identify
Possible
Initiatives
5.3 Estimate
Skills
Required
5.4 Estimate
Time
Required
Scoping
5.7 Refine
Rubrics
5.8 Define
Scenary
Scope
5.9 Tailor
Scenary
Documents
5.10 Create
Scenary
Image
5.11 Clone
Scenary
Image
5.12 Define
Scenary
Technology
Guide
6.3 Modify
KPIs
5.5 Calculate
Initiatives
Weights
7.1
Validate and
Fix
Scenario
Builders
Figure 6: Academic Projects phase.
PP1 PP2 PP3 PP4 PP5 PP6 Total
Skills
ponder
ation
3 2 1 1 2 6 -
I1 3 1 3 1 3 5 -
Points 9 2 3 1 6 30 51
I2 5 1 1 5 3 5 -
Points 15 2 1 5 6 30 59
Figure 7: Architectural Effort Calculation.
ral project. By dedication we refer to the time and
level of expertise expected to complete the tasks of
each phase. Then, the instructor calculates the weight
of each initiative by multiplying the effort points in
each phase of the project with the skills needed in that
phase. Each of the final values from the different pha-
ses are finally summed to get the final architectural
effort required to complete the initiative. These ope-
rations can be appreciated on Figure 7.
After that, the instructor contacts a group of in-
structors and experienced IT architects to perform an
expert’s judgement to judge the approximate time that
each initiative would take to be completed. Candidate
initiatives are then prioritized: the most eligible ones
are those with a high architectural effort but with a 4
month or less time frame, period in which the projects
will take place. The instructor then selects one which
meets the stated criteria.
Once the initiative is selected, rubrics with the
evaluation criteria are refined, detailing which of the
project phases are the most important and therefore
deserve a greater weight on the student overall marks.
Additionaly, instructors select the documentation that
students need in order to understand the company and
make the initiative real. Also, copies are made of
the virtual machines hosting the scenario implemen-
tation. There has to be a copy for every team of stu-
dents working on the project course, including a de-
ployment guide and information about the technolo-
gies in which the scenario is based on.
4.1.6 Project Development
During the project development stage, the students
have to go through the phases of an IT project in order
to design and build the business an technology capabi-
lities required to materialize the initiative. Depending
on the initiative, changes will be required in the diffe-
rent architectural domain models. For example, if we
are talking about creating a whole new sales channel,
there could be more modifications to the models than
if we are talking about altering some processes. Then,
in order to correctly construct the initiative, students
must follow some or all the stages of the process for
an IT architecture project as stated in section 2.
4.1.7 Project Integration
The key to having a reliable and self-sustainable sce-
nario lies in this step because scenario builders can
take the work done by the students, revise, adjust and
add it to the scenario. Basically, scenario builders
study the works done by the students and select the
best ones. Then, after some modifications or adjust-
ments, they integrate the new components to the sce-
nario. This process assures the last requirement of a
useful case: evolving in time as the scenario is always
changing and improving.
5 CASE STUDY: ECOS
The Software Construction Specialization (ECOS) is
a postgraduate program at Universidad de los Andes
oriented towards information technology professio-
nals who want to acquire an architect profile. The
program combines seven theoretical courses and three
integrator projects (see Figure 8). The first ones
give students the foundation and concepts of the best
practices in enterprise software construction. The
projects provide a space in which students can apply
their knowledge in the development of different sta-
ges of an IT architecture project process.
CSEDU 2017 - 9th International Conference on Computer Supported Education
114
Theoretical
Class 1
Theoretical
Class 2
Theoretical
Class 3
Integrator
Project 1
Integrator
Project 2
Theoretical
Class 5
Theoretical
Class 6
Theoretical
Class 7
Integrator
Project 3
Theoretical
Class 4
4 months 4 months
2 months
Figure 8: ECOS main structure.
Oracle WebCenter Suite
Oracle Service Bus
Oracle BPM Oracle BAM
Oracle Service Bus
Legacy Applications SugarCRM
Figure 9: MPLA Components Model.
In ECOS’ projects, the IT laboratory is a key tool
as it provides scenarios for the students to work. The
scenario which has been used for the last six years is
the Marketplace of the Alps (MPLA), a fictional sce-
nario representing a marketplace between common
goods retailers and manufacturers. The rest of this
section shows a brief description of the MPLA scena-
rio, the way ECOS used it during the past four years,
and an evaluation of the laboratory.
5.1 The Scenario: MPLA
Marketplace of the Alps is a company which pro-
vides a virtual system where different retailers can
acquire products from a variety of options given by
manufacturers or suppliers. Manufacturers offer their
products, retailers specify what they want to buy and
MPLA manages the transactions between them. The
operation of MPLA revolves around four types of
transactions:
PRICAT: Replicate product catalog (commercial
supply) of a particular manufacturer to all retailers re-
gistered in MarketPlace that are interested in buying
the product.
PO (Purchase order): Receive orders from a par-
ticular retailer and direct it to a specific set of manu-
facturers. The purchase order should only consider
products for which the retailer has expressed interest
in acquiring.
DA (Dispatching Advice): Receive notification of
release, in response to a purchase order. This notice is
sent from the manufacturer and is routed to the retailer
which generated the PO.
RMA (Return Material Advice): Receive messa-
ges of merchandise return from the retailer and direct
it to the manufacturer who made the delivery of the
products (DA) to that entity.
The business model that supports the MarketPlace
today is quite simple: Retailers generate a purchase
order (PO) to the MarketPlace. The order mainly
has: the desired product, maximum delivery date and
maximum date associated auction duration. Then,
the MarketPlace routes the order to all manufacturers
who offer products that can fill the order. A reverse
auction associated with the PO is created in order for
the manufacturers to bid on. In the reverese auction,
the manufacturers make their offers and the bid with
the lowest price that meets the delivery date requested
by the retailer is selected as the winner. Then, both
the winning manufacturer and the retailer are notified
and the manufacturer proceeds to generate a dispatch
to the retailer.
MPLA’s operation is totally based on different
technology solutions. These solutions are mainly pro-
vided by Oracle Technologies and its integration is
made through web services. MPLA’s technology so-
lutions architecture and Business Model are shown in
Figure 9 and Figure 10 respectively.
5.2 Usage
In ECOS, projects start with the definition of initia-
tives. As it is a graduated program, initiatives must
present hard challenges and may involve the develop-
ment of all the IT architecture project steps. The steps
the students have to perform in the project are divided
into three courses thoughout a year (Project 1, 2, and
3) as shown in Figure 11.
To exemplify the initiatives selection, Table 2 pre-
sents the candidate initiatives identified by ECOS in-
structors on 2014. All of them were evaluated to
determine the effort needed to materialize each one.
Using an IT Laboratory for Training IT Architects
115
Figure 10: MPLA Canvas Model.
Planning
Information
Gathering
Analysis
Design Re-design
Implementation
Re-design
Project 2
Project 3
Roadmap
Implementation
Project 1
Figure 11: Project integrator courses distribution.
This evaluation was made by 4 ECOS instructors and
then summarized. Then, taking those results and the
skills required by each phase calculation, the architec-
tural effort was determined, as it is shown in Figure
12.
Table 2: Candidate initiatives.
ID Initiative
I1 Customer knowledge improvement
I2 Reputation based selection
I3 New mobile app
I4 Marketing campaigns
After that, the instructors performed the expert’s
judgement with the purpose of making an estimate of
the time the students will need to complete the ini-
tiative. Then, taking the architectural effort and the
average time determined by the instructors, the best
PP1
PP2
PP3
PP4
PP5
PP6
Total
Skills
ponderation
7
8
6
13
12
8
I1
3
5
3
5
5
5
Points
21
40
18
65
60
40
244
I2
1
5
3
3
3
3
Points
7
40
18
39
36
24
164
I3
5
5
5
5
5
5
Points
35
40
30
65
60
40
270
I4
1
3
5
3
3
3
Points
7
24
30
39
36
24
160
Figure 12: Architectural Effort.
Initiative
Architectural Effort
Estimated Time
I1
244
6 months
I2
164
5 months
I3
270
8 months
I4
160
4,5 months
Figure 13: Initiatives selection.
initiative was selected, as seen in Figure 13.
Then, the documentation and virtual machine co-
pies were given to the thirty students divided in six
groups. They started Project 1 reviewing and gather-
ing additional information of MPLA in order to start
making the analysis, design and roadmap phases cor-
rectly. Parallel to the time of Project 1 the students
were also acquiring knowledge and useful concepts
in their other courses which could be applied to the
CSEDU 2017 - 9th International Conference on Computer Supported Education
116
stages of the project. During Project 2 they were fa-
ced with the scenario implementation which has the
components presented on Figure 9. During this, a tu-
torial was provided to the students in order to fami-
liarize them with the scenario’s technologies. They
were also allowed to refine the design and roadmap
defined in Project 1. Finally, in Project 3 the students
made the modifications to the legacy applications and
enterprise systems in order to develop their designed
customer knowledge improvements.
5.3 Evaluation
The evaluation of the IT laboratory was made in two
ways. The first one was the continuous evaluation
with the experts to validate coherence and pertinence
of the built scenarios. This first evaluation was exe-
cuted regularly as the IT laboratory was modified re-
gularly. The second one was the IT laboratory impact
on ECOS students. As we stated that the IT labora-
tory may facilitate the IT architects training and pro-
vide an environment in which students can get closer
to an ITA project real experience, it is therefore ne-
cessary to measure students improvement on the aca-
demic and professional fields. For measuring this,
we took three different indicators: the improvement
of their marks along the courses; the program satis-
faction surveys, and alumni surveys. We made our
assessments in four different cohorts of the students
of our program.
5.3.1 Marks Improvement
In this indicator we measured progress across the sta-
ges of the project, using the three integrator projects
as check points. On each checkpoint, students must
be faced with a stakeholder meeting and present their
results as they would do in front of the customer. This
stakeholder meeting is composed by industry experts
and instructors who give the students feedback and
state needed modifications. We found that the first
check point is usually hard on the students as it is
composed by the analysis and design steps and they
usually have a freat deal to modify and improve. The
second one is a refining of the previous step and a first
approach to the implementation so they usually have
a rough start on it too.
Finally in the last integrator project they have to fi-
nish the refinement of the design and complete the im-
plementation. It is clearly the hardest iteration of the
project but as they have previously worked on the de-
sign and implementation, and at that point they have
learned more concepts from theoretical courses in the
specialization, they usually improve their results at
Project 1 Project 2 Project 3
0
1
2
3
4
5
2011
2012
2013
2014
Average
Figure 14: Marks improvement.
2011 2012 2013 2014
0
1
2
3
4
5
Figure 15: Average qualification satisfaction surveys.
the end of this phase. Results of this evaluation per-
formed yearly during four years of the specialization
with student groups of about forty people are shown
in Figure 14. We can see a growing model through
the results of the first checkpoint and the last. These
results help us understand if the continuous practice
benefits the students performance on an ITA projects
development according to the experts opinion.
5.3.2 Satisfaction Surveys
Another relevant indicator we considered was the stu-
dent’s perception of the entire specialization program.
For that we sent students satisfaction surveys at the
end of each individual course during the same four ye-
ars of the previous indicator. Measuring each course
gave us the possibility to adjust courses individually
and also made an average in order to know the stu-
dent’s opinion on the program.
In the surveys we asked students to give a quali-
fication from 1 to 5 according to how satisfied they
were with the different courses; measuring contents,
instructors, materials and of course the IT laboratory
as the main course’s support. We found that the ge-
neral perception was undoubedly good as the results
from the four year period were high (See Figure 15).
5.3.3 Alumni Surveys
As exposed previously, our intention is to generate
professionals better suited for the real life projects.
So, in order to find out if we were really making a
Using an IT Laboratory for Training IT Architects
117
S
K
1
S
K
2
S
K
3
S
K
4
S
K
5
S
K
6
S
K
7
S
K
8
S
K
9
S
K
1
0
S
K
1
1
S
K
1
2
S
K
1
3
S
K
1
4
S
K
1
5
S
K
1
6
S
K
1
7
S
K
1
8
S
K
1
9
S
K
2
0
S
K
2
1
S
K
2
2
S
K
2
3
0
1
2
3
4
5
6
7
Figure 16: Answer to question: Indicate from 1 to 7 how much the following skills strengthened during your passing through
the program, where 1 implies that you did not develop the skill and 7 that you developed it completely.
Yes
No
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Figure 17: Answer to question: Do you think that during
the courses Project 1, Project 2 and Project 3 you applied
the concepts acquired in the other program’s courses?
Yes
No
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Figure 18: Answer to question: Do you think that the use of
a tool like the IT Laboratory was useful for your education?
change in our students’s professional life, we ques-
tioned our alumni. Here are the results of the most
important questions as answered by 35 ECOS alumni
students (Figures 16, 17 and 18). As we can see, the
surveys show a positive impact and a high develop-
ment of the desired skills, proving the pertinence of
the approach. Nonetheless, we are going to continue
improving it in order to get even better results, have
more reality simulated cases and help train more stu-
dents.
6 CONCLUSIONS
This paper addresses the difficulty of complementing
the training of IT architects with practical exercises
and not only theoretically. Given that it is unlikely
that the architects in training put their knowledge into
practice in real companies, it proposes the creation of
an IT laboratory that recreates real companies. These
virtual companies called scenarios have bussiness and
IT components and they give students an environment
to practice and reinforce their abilities in the develop-
ment of ITA projects.
For the scenarios to be useful to students, they
have to meet three requirements: coherence, com-
plexity and evolution. With this objective, the paper
explains in detail how during the scenario’s creation
there have to be industry experts involved who can
evaluate the consistency of it according with its indu-
stry and size. Moreover, the scenarios creation pro-
cess takes into account the insertion of imperfections
and inconsistencies like the ones in real companies.
Finally, during the scenario’s usage, it is explained
how they were given feedback and new components
in time.
Then, the scenarios are useful for students wor-
king in projects that integrate the use of theoretical
concepts. This approach was evaluated in a postgra-
duate program named ECOS during four consecutive
years. During that time the combination of theoreti-
cal courses and practical projects based on the IT la-
boratory was evaluated. The evaluation was focused
on three aspects: grades improvement, student satis-
faction and impact on graduates. All these evaluations
yielded positive results, proving that the approach fa-
cilitated the acquisition of the skills necessary for an
architect to face real projects.
In conclusion, practice is essential in the training
of architects, but in order for it to be effective, it must
be done in contexts that present adequate challenges
for students. In this sense, the creation of complex vir-
CSEDU 2017 - 9th International Conference on Computer Supported Education
118
tual scenarios supported in real technology and with
a complete business definition, can be an alternative
of high impact and effectiveness. This continuous
practice can have a huge impact on IT architects’s trai-
ning as it reduces the timeframe needed for a profes-
sional to acquire the insight and skills for executing
and IT Architecture project.
REFERENCES
Clements, P. (2010). Certified software architects. In IEEE
Journals and Magazines. IEEE.
Felder, R. M. and Brent, R. (2003). Designing and Teaching
Courses to Satisfy the ABET Engineering Criteria.
Harrison, R. (2011). TOGAF 9.1 Certified Study Guide. Van
Haren Publishing.
Humphrey, W., Chick, T., Nichols, W., and Pomeroy-Huffn,
M. (2010). Team software process body of knowledge.
Pittsburg, USA: Software Engineering Institute, Car-
negie Mellon.
IEEE (2005). Professional certification of software engi-
neers: the csdp program. In IEEE Journals and Ma-
gazines. IEEE.
International Association for Software Architects (2016).
Job description.
Kalampokis, E., Tambouris, E., Zotou, M., and Tarabanis,
K. (2012). The enterprise architecture competence
framework.
Kendall, K. and Kendall, J. (2014). Systems analysis and
design 9th edition. Pearson.
Markham, T. (2011). Project based learning. In Teacher
Librarian. Information Age Publishing.
Marks, M. (2016). What is IT Architecture.
McCormick, M. (2008). Expanding the College Classroom:
Enhancing Engineering Education Through Project-
based Service-learning. Tufts University.
Scherer, S. and Wimmer, M. (2011). Analysis of en-
terprise architecture frameworks in the context of e-
participation. In Proceedings of the 12th Annual Inter-
national Digital Government Research Conference:
Digital Government Innovation in Challenging Times.
ACM.
Shuja, A. K. and Krebs, J. (2007). IBM Rational Unified
Process Reference and Certification Guide: Solution
Designer (RUP). IBM.
The Open Group (2011). TOGAF 9.1 - The Open Group Ar-
chitecture Framework Version 9.1. The Open Group.
Wankel, C. (2005). Educating managers through real world
projects. In Research in Management Education and
Development. Information Age Publishing.
Using an IT Laboratory for Training IT Architects
119