A BOTTOM-UP APPROACH FOR THE REPRESENTATION AND

CONTINUOUS UPDATE OF TECHNOLOGY ARCHITECTURES

IN PUBLIC ADMINISTRATION

Position Paper

Jo˜ao Soares, Jos´e Tribolet and Andr´e Vasconcelos

Instituto Superior T´ecnico, Av. Rovisco Pais 1, 1049-001 Lisboa, Portugal

Keywords:

Information systems architecture, Technology architecture, Public administration, Bottom-up, Continuous up-

date, Autodiscovery.

Abstract:

In organizations where there are not any concerns about updating Information Systems Architecture (ISA)

models in a strict and automatic fashion, business requirements and pressures frequently lead to an increasing

gap between current Information Systems and the latest version of their ISA and, in particular, their Technol-

ogy Architecture (TA) models, when they exist. One of the causes for the lack of “investment” in TA models

is the considerable effort required to “discover” infrastructural features that serve as input to the development

of architectures. This work is focused on devising a bottom up approach for the representation and continuous

update of TAs in Public Administration (PA) using tools to automatize the discovery of architectural evidences

(such as logs or network events) and a process based on the annotation mechanism to enable interaction con-

texts that allow actors to make explicit their knowledge about their activities through graphic representations.

1 INTRODUCTION

As result of a crescent globalization, competition

among organizations is becoming more and more

driven by it’s capacity and ﬂexibility of reorganiza-

tion and redesign of business processes and business

strategies (Vasconcelos, 2007).

Some of the implications that arise from the need

to reorganize and redesign business processes and

business strategies reﬂect themselves on the demand

for IT able to support those new requirements.

Enterprise Architecture (EA) (and by association,

ISA and TA) is considered an essential piece to the

resolution of the challenges that emerge as a result

from the organization’s need quickly readapt them-

selves and their Information Systems (ISs) (Land,

Martin Op ’t, et al, 2008). Thus, the explicitness of an

ISA has a key role in the construction of ISs that aim

to contribute proactively to the alignment between

business realities and IT realities, to deﬁne technol-

ogy strategies, to control and manage more efﬁciently

ISs, to ensure durable, ﬂexible and adaptable to busi-

ness needs ISs, and ﬁnally to increase the portability

of applications and ease the development and alignm-

ent of ITs with (changing) business strategies.

This investigation will be focused in a more re-

strict problematic inside EA - the reality regarding

technologies managed by organizations to support

their processes. At a ﬁrst glance, this work will cover

tree great issues: the capture of that reality, the map-

ping between the results of the capture and archi-

tectural models and ﬁnally, the continuous update of

those models.

This document is divided in 5 sections. Section

2 establishes the objectives and motivations of this

work. Section 3 is about the State of the Art regarding

the areas of interest that intersect with this work. In

section 4 there is a description of the architecture of

the solution. Finally, section 5 has conclusions over

the work developed until now.

2 CLARIFICATION OF THE

PROBLEM AND OBJECTIVES

Considering the previously identiﬁed issues related to

the beneﬁts of a general IT awareness in an organiza-

tion, it is possible to conclude that, although there is

467

Soares J., Tribolet J. and Vasconcelos A..

A BOTTOM-UP APPROACH FOR THE REPRESENTATION AND CONTINUOUS UPDATE OF TECHNOLOGY ARCHITECTURES IN PUBLIC

ADMINISTRATION - Position Paper.

DOI: 10.5220/0003419504670470

In Proceedings of the 13th International Conference on Enterprise Information Systems (ICEIS-2011), pages 467-470

ISBN: 978-989-8425-56-0

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

a common agreement in the advantages and potential

arising out of the speciﬁcation of an ISA, it is still not

possible to represent that architecture at different lev-

els and their relationship with the business model in

a standardized, universal, simple and simultaneously

with the richness and rigor required for subsequent

inspection and/or simulation of different business sce-

narios and technology (Boar, B., 1999).

More speciﬁcally, in the context of PA, there is a

lack of global knowledge of the current ISA, nor are

there any automatic methodologies or processes de-

ﬁned to collect and identify architectural evidences.

Those evidences would then be a valid input to the

construction of a TA, resulting in a bottom-up ap-

proach, as individual base elements of the system are

ﬁrst speciﬁed in great detail.

Taking this context as a starting point, the fact

that drives this work lies in precisely the lack of a

global knowledge and collaborative update of the cur-

rent ISA models in PA. To address this problem, there

is one question that rises up in the ﬁrst place, and con-

stitutes the problem of this work: ”What is the TA of

PA?”. This question is clearly too much broad, so our

work will be focused in a particular context of the Por-

tuguese PA, but the techniques to be applied will be as

much transversal as possible, in order to be replicated

into other contexts.

The question that frame this investigation can then

be decomposed into other two modular questions:

• ”What architectural evidences should be consid-

ered in order to construct a TA?”’ The answer to

this question will lead to a well deﬁned set of ar-

chitectural evidences, ranging from, e.g., simple

logs produced by servers, to network events. The

approach to to so, will take into account different

IT contexts of the Portuguese PA.

• ”How to automatically collect and identify archi-

tectural evidences in PA?” This is one of the chal-

lenges of this work, because it will allow an efﬁ-

cient, fast and ruled collection of data, which will

be a major improvement regarding the creation of

TAs from scratch. On the other hand, in cases

where architectures are already modeled, will al-

low them to be much more maintainable since the

process of incorporating changes will be much

more agile.

• ”How to map architectural evidences into up-

dated, trustworthy and reliable TA models?”’ The

answer to this question urges because there is a

recognized difﬁculty in maintaining models up-

dated and aligned with the reality.

3 RELATED WORK

3.1 EA Methods and Frameworks

An enterprise architecture framework collects to-

gether tools, techniques, artifact descriptions, process

models, reference models and guidance (methods)

used by architects in the production of enterprise-

speciﬁc architectural descriptions. A framework can

also deﬁne views that are representations of systems

from the perspective of a related set of concerns (e.g.,

top management or operational), and have a dedicated

modeling language or extend existing ones.

3.1.1 Zachman Framework

Zachman Framework was introduced by John Zach-

man in 1987. It was the ﬁrst EA framework and it is

used in numerous domains, providing a view of the

subjects and models needed to develop a complete

enterprise architecture. In a “big picture”, this frame-

work is a logical structure (matrix) for classifying and

organizing the descriptive representations of an enter-

prise: on a vertical axis it provides multiple perspec-

tives of overall architecture, and on a horizontal axis,

a classiﬁcation of the various artifacts of the architec-

ture (Zachman, 2008) (Lankhorst and et al., 2009a)

The purpose of this framework is to provide a ba-

sic structure which supports the organization, access,

integration, interpretation, development, management

and changing of a set of architectural representations

(artifacts) of the organization’s ISs.

As a contribution to this work, the Zachman

Framework can be quite useful as a tool for organiz-

ing and classifying relevant architectural artifacts that

will be developed during this investigation. The inter-

section between the last two rows of the matrix (De-

tailed Representations and Technology Model) and

the three ﬁrst columns (Data, Function and Network)

can be assumed as a repository of representations

about a technical infrastructure that can serve as a

baseline for the construction of an ISA.

3.1.2 TOGAF

The Open Group Architecture Framework (TOGAF),

a framework developed and maintained by The Open

Group Architecture Forum and its members, is a

global standard for assisting in the acceptance, pro-

duction, use and maintenance of architectures based

on a iterative process (Josey, 2009) (The Open Group,

2009).

ICEIS 2011 - 13th International Conference on Enterprise Information Systems

468

TOGAF covers the development of four related

types of architecture, subsets of a global EA: Busi-

ness Architecture, Data Architecture, Application Ar-

chitecture and TA.

There are two important components of TOGAF

according to the scope of this project (The Open

Group, 2009):

• The Architecture Development Method (ADM)

plays a central role in TOGAF and describes

cyclically how to develop a complete enterprise

architecture, providing guidance on a number of

levels (Lankhorst and et al., 2009b):

• The Enterprise Continuum comprises a num-

ber of reference models and methods, such as the

Technical Reference Model, The Open Group’s

Standards Information Base and the Building

Blocks Information Base, for classifying archi-

tecture and solution artifacts, showing how they

evolve and correlate to each other.

The Technical Reference Model (TRM), which

provides a model and taxonomy of generic platform

services, can be used in this work to structure a co-

herent description of the components that are part of

the TA of an IS.

3.1.3 Framework CEO 2007

Proposed by Vasconcelos in (Vasconcelos, 2007) this

framework features a taxonomy of concepts used to

deﬁne a ISA (architectural primitives).

The meta-model of CEO 2007 is organized in the

following architectures: Business Architecture, Orga-

nizational Architecture and Information Systems Ar-

chitecture

This framework will serve as the conceptual basis

for the description of TAs and ISAs during this work,

because it was developed in the context of the group

CODE

, as this work is.

3.2 Application Discovery and

Dependency Mapping

Application discovery is the process of automatically

analyzing artifacts of a software application. De-

pendency Mapping creates visibility between appli-

cations and infrastructure dependencies.

The use (and possible extension) of software tools

that implement these features could be a major value-

adding element in the pursuit of the objectives of this

investigation. Leveraging the power of automation,

Center for Organizational Design and Engineering -

INESC

automated application discovery and subsequent de-

pendency mapping, can capture, connect and unveil

intricate relationships including the way in which ap-

plications behave and relate to the TA on which they

rely.

Automated application discovery normally lever-

ages an effective non-agent-based discovery method

- passive discovery - to automatically discover the

structural and behavioral aspects of applications. Pas-

sive discovery operates by watching the network traf-

ﬁc, examining all the applications as they execute, and

then identifying relationships based on real business

usage. Passive discovery also means that the manage-

ment burden of maintaining software agents is null.

Passive discovery is just a part of the equation re-

garding these systems. Some products often use a hy-

brid approach, where active discovery is also used to

enable the collection of deep and fundamental data

about conﬁguration details.

3.3 A Dynamic Update Process

The present section is about describing a process

to continuously update an enterprise model (Castela

et al., 2010). In the process explained in this sec-

tion, organizational actors act as active updaters of

the AS-IS model, through the comparison between

the modeled activities and the ongoing real executed

activities, becoming key agents in reducing the gap

between the organization and its representation.. The

following text expresses the essence of PROASIS

(business process model dynamic updating process):

“The “client” of PROASIS (corresponding role of the

operational model that detects misalignment between

the model and “reality”) wants to update the model, so

it makes an annotation (update request). This update

request is received by the modeler (which is who ac-

tually update the model if the annotation is approved)

and by the reviewers. When reviewers receive the an-

notation, they can begin the revision of the annota-

tion (which is optional). The approval of the anno-

tation is made based on the analysis of the annota-

tion (update request) and reviews. If the annotation

(request update) is approved, the model will be up-

dated and delivered to the “client””. Besides the fact

that PROASIS is suited to business processes, it can

be adapted in this work in order to map architectural

evidences into updated, trustworthy and reliable TA

models. The idea of using an extended version of

PROASIS in this work enables a collaborative main-

tenance of the TA models originally incipiently build

using mechanisms of autodiscovery. On the other

hand, PROASIS and the annotation mechanism could

be used in an earlier stage: to ”decide” within an or-

A BOTTOM-UP APPROACH FOR THE REPRESENTATION AND CONTINUOUS UPDATE OF TECHNOLOGY

ARCHITECTURES IN PUBLIC ADMINISTRATION - Position Paper

469

ganization, what would be the most commonly ac-

cepted language to represent TAs.

4 SOLUTION’S ARCHITECTURE

AND METHODOLOGY

This section is about describing the steps that the so-

lution’s architecture will follow.

According to the questions that constitute the

problem that drive this investigation, as well as all

the related work described earlier, following, there is

a description of each stage/landmark of the proposed

solution facing the initial motivation to this problem:

• Contexts. It is the phase where different relevant

contexts (entities that manage IT assets) are ana-

lyzed in order to propose a structure of concepts

to describe the manifestations of IS and its TA ex-

hibited through architectural evidences, consider-

ing terms introduced by TRM and CEO 2007.

• Analysis & Evaluation. In this stage, two activi-

ties take part:

– Analysis of CEO 2007 regarding it’s capability

of expressing detailed TA aspects (e.g, regard-

ing network connections, ﬁrewalls, etc.).

– Analysis of Application Discovery tools regard-

ing it’s extensibility potential.

• “Products”. This is the phase where “visible

work” is done regarding tree facets:

– CEO 2007: TA extensions; Mapping between

the structure of concepts; Adaptation of the

continuous cycle of monitoring and veriﬁca-

tion of the IS and veriﬁcation of it’s TA real-

ity to the reality of automatic discover of archi-

tectural evidences and continuous collaborative

update.

– Application discovery tools: Necessary exten-

sions.

– PROASIS: Adaptation to TA representation and

maintenance.

The architecture of the desired bottom up ap-

proach can then be described brieﬂy in tree steps:

1. Use PROASIS prior to any representation, to

agree, inside an organization, on the notation to

represent the TA.

2. Perform Autodiscovery.

3. Use PROASIS as repository to the early represen-

tations and tool to support collaborative update.

5 CONCLUSIONS

EA (ISAs and TAs in particular) are regularly rele-

gated to a secondary role in the context of organiza-

tions, due to factors such as counterculture; it is not

considered as an essential piece regarding the organi-

zation’s survival; it is a job that consumes a certain

amount of time and requires considerable effort, and

the companies, eager to get quick results, tend to see

architecture as an effort too high with too many actors

involved within the organization.

This last reason has particular relevance in the

context of PA due to funding reasons: money from ﬁ-

nancing is much more easily allocated in areas/project

that have the potential to produce “visible” impact.

This work began by the clariﬁcation of the prob-

lem together with the motivations towards the solu-

tion. Regarding the related work, several EA Meth-

ods and Frameworks were revisited according to the

potential to be used in this investigation as well as Ap-

plication Discovery tools (to quickly capture the in-

frastructural reality of an organization) and a process

to enable collaborative update of TA models.

The course of this investigation will follow the

steps described in ´the previous section to achieve a

bottom up approach.

REFERENCES

Boar, B. (1999). Constructing Blueprints for Enterprise IT

Architecture. John Wiley & Sons, New York.

Castela, N., Zacarias, M., and Tribolet, J. (2010). Business

Process Model Dynamic Updating. CENTERIS 2010.

Josey, A. (2009). TOGAF

Version 9 Enterprise Edition.

White Papper, The Open Group.

Land, Martin Op ’t, et al (2008). Enterprise Architecture

(The Enterprise Engineering Series): Creating Value

by Informed Governance, page 5. Springer.

Lankhorst, M. and et al. (2009a). Enterprise Architecture

at Work, pages 25–26. Springer, Heidelberg, second

edition.

Lankhorst, M. and et al. (2009b). Enterprise Architecture

at Work, pages 26 – 29. Springer, Heidelberg, second

edition.

The Open Group (2009). TOGAF

Version 9. Van Haren

Publishing.

Vasconcelos, A. (2007). Arquitecturas dos Sistemas de

Informac¸˜ao: Representac¸ ˜ao e Avaliac¸˜ao. PhD thesis,

Instituto Superior T´ecnico.

Zachman, J. (2008). John Zachman’s Concise Deﬁnition of

the Zachman Framework. Zachman International.

ICEIS 2011 - 13th International Conference on Enterprise Information Systems

470