IDENTIFYING RUPTURES IN BUSINESS-IT COMMUNICATION

THROUGH BUSINESS MODELS

Juliana Jansen Ferreira, Renata Mendes de Araujo and Fernanda Araujo Baião

Research and Practice Group in Information Technology (NP2Tec), Graduate Program in Informatics (PPGI)

Federal University of the State of Rio de Janeiro (UNIRIO), Av. Pasteur 458, Urca, Rio de Janeiro, RJ, Brazil

Keywords: Information Systems specification, Communicability, Communication ruptures, Business modeling,

Business-IT alignment, Business-IT communication, Communicability evaluation.

Abstract: In scenarios where Information Technology (IT) becomes a critical factor for business success, Business-IT

communication problems raise difficulties for reaching strategic business goals. Business models are

considered as an instrument through which this communication may be held. This work argues that the

business model communicability (i.e., the capability of a business model to facilitate Business-IT

communication) influences on how Business and IT areas understand each other and on how IT teams

identify and negotiate appropriated solutions for business demands. Based on the semiotic theory, this

article proposes business model communicability as an important aspect to be evaluated for making

Business-IT communication cycle possible, and describes an exploratory study to identify communication

ruptures in the evaluation of business models communicability.

1 INTRODUCTION

The fast evolution of current organizations demands

Information Technology (IT) and Business areas to

be aligned, so that changes and information systems

(IS) evolution may occur in a more efficient way,

without great impacts for the organization business

outcomes. The combination of unplanned IT

development and the dynamic changes of business

strategies are turning the IT support to business

inefficient and chaotic, damaging the alignment

between them (Barjis, 2008) (Plazaola et al, 2006)

(Ekstedt et al, 2005) (Marques and Sousa, 2003).

In order to transform a business need into an IS

specification, the organizational context where that

need was identified must be known both by IT and

business areas. This organizational context

comprises, among others: its activities, the

information handled during activities execution, the

business rules applied, IS already supporting the

business activities. Great part of this information

may be understood and represented through the use

of business models (Ericsson and Penker, 2000)

(Sharp and Mcdermott, 2008).

Business and IT alignment depends on a number

of components, one of them being communication

(Luftman and Kempaiah, 2007). The Business-IT

alignment can be achieved when both areas have the

same understanding about the business context.

Business models are considered as an instrument

through which IT area can share the same

understanding of the business area of their working

contexts (Barjis, 2008). Research indicates the use of

business modeling as a facilitator of communication

for IS specification, helping the interaction between

the stakeholders, both from business and IT parts,

business analyst and IT analyst (Barjis, 2008) (Barjis

et al, 2006) (Yu, 2005) (MacKnight et al, 2005)

(Bittencourt and Araujo, 2008) (Cruz, 2004) (Van

der Aalst and Dehnert, 2004). The IT analyst needs

to understand the business reality so he can specify a

IS capable to support that business needs.

Considering the business model as a means

through which this the communication between

business analyst and IT analyst takes place, the

capability of a business model to facilitate the

communication (which we will call

communicability) may be considered as an important

feature for Business-IT alignment to be effective.

The main issue here is how to improve the

understanding of the business context by the IT

analyst so that he/she can specify ISs aligned with

business contexts represented in business models. IS

specification, in this work, concerns the

Jansen Ferreira J., Mendes de Araujo R. and Araujo Baião F. (2010).

IDENTIFYING RUPTURES IN BUSINESS-IT COMMUNICATION THROUGH BUSINESS MODELS.

In Proceedings of the 12th International Conference on Enterprise Information Systems - Information Systems Analysis and Speciﬁcation, pages 44-51

DOI: 10.5220/0002875900440051

 SciTePress

identification of main IS functional requirements

and data conceptual models.

This research proposes the use of Semiotics as an

approach to the evaluation of business models

communicability. Semiotics, which is applied and

discussed in many areas of research as psychology,

anthropology, and philosophy, is the study of signs,

the relation among those signs and what they mean

all together (Pierce, 1958) (Chandler, 2002). With

this purpose in mind, semiotics concepts are applied.

This research proposes the application of

semiotics concepts to business models, considering

those models as a set of signs and its relations that

have meaning for those who model, who analyze or

use the models as a communication instrument. In

this research case, the focus is the business model as

the message being communicated by the business

analyst to the IT analyst to specify IS, helping on the

interaction between the stakeholders from IT and

business parts. This work also proposes the

definition of communication ruptures, as defined by

the HCI (Human-Computer Interaction) area

semiotic theory - Semiotic Engineering- to evaluate

the communicability features in systems interfaces

(De Souza, 2005) applied to business models

communicability evaluation.

This paper discusses the how to conceptualize

business models communicability, taking the

semiotics concepts as foundation. This paper also

presents an exploratory study from which a set of

communication ruptures could be identified when a

business model is used as a reference to specify IS.

The search for communication ruptures aims at

evaluating the communicability features of business

models. The specific points of the business model

where communicability needs to be improved are

identified. Also by knowing the kind of

communication problems that a business models

might present, some actions can be taken even at

modeling time, when the business models are being

designed. This way, the business model has a higher

probability to be a powerful communication

instrument for Business-IT alignment.

This paper presents at section 2 the concepts of

business modeling as its relation to IS specification.

Section 3 presents the concepts of semiotics and its

application. Section 4 defines communicability for

business models. Section 5 presents an exploratory

study on evaluating business model

communicability, analysis and considerations.

Section 6 presents a list of preliminary

communication ruptures identified during the

exploratory study. Section 7 concludes the paper and

outlines the following steps of the research.

2 BUSINESS MODELS FOR

INFORMATION SYSTEMS

SPECIFICATION

Business modeling may have different objectives.

Some approaches focus on business process

improvement (Yu, 1995), others consider the need to

identify requirements to develop IS that support the

business models (MacKnight et al, 2005)

(Bittencourt and Araujo, 2008) (Cruz, 2004) and

others consider business model automation. (Van der

Aalst and Dehnert, 2004) (Iendrike and Araujo,

2001). At the present research, the business model is

understood as an instrument to support the

communication between the stakeholders of an IS

implementation, business analyst and IT analyst

(Figure 1), when there exists a business context and

need which demands IT solutions and support.

Figure 1: Business models as instrument of

communication between business and IT.

The communication we focus is the one taking

place when an IT analyst specifies an IS using the

business model as the representation of how

business occurs. In this situation, the business

analyst, who modeled the business, is trying to

communicate the business context where the IS

should be inserted to the IT analyst. In this way, we

can consider that the IT analyst interacts with the

business analyst through the business model.

There are several methods for specifying IS from

business models (Barjis, 2008) (Yu, 2005)

(MacKnight et al, 2005) (Bittencourt and Araujo,

2008) (Cruz, 2004) (Van der Aalst and Dehnert,

2004). All of them present the following premise to

be successfully executed: the business models must

communicate to IT analyst what is necessary to the

IS specification that will support that business

model. The business models must communicate the

business context, presenting what the business

analyst would inform to the IT analyst so the IS

IDENTIFYING RUPTURES IN BUSINESS-IT COMMUNICATION THROUGH BUSINESS MODELS

specification could be aligned with the business

needs.

Therefore, it is important to evaluate if the

business models that are being produced can be an

effective communication instrument for specifying

IS. The subject of evaluation would be the business

model communicability, not the model itself. Its

communicability can be identified and evaluated

when the IT analyst is using the business model in

order to specify the IS.

This communicability evaluation should be able

to identify communication ruptures - the moments

when the business model was not able to

communicate, or some miscommunication occurred.

The number and type of the communication ruptures

resulting from this evaluation could be used as input

for improving the business model regarding its

communicability feature towards being a better

communication tool between business and IT

(Figure 2). This work attempts to identify a set of

communication ruptures which can be further used

both as reference for communication evaluation

methods as well as guidelines for the definition of

business modeling heuristics for communicability .

Figure 2: Business model communicability evaluation

providing improvement business-IT alignment for IS

specification.

3 SEMIOTIC THEORY AND ITS

APPLICATION

Semiotic is a multidisciplinary theory related to

various areas of knowledge such as psychology,

anthropology, philosophy, linguistics and others;

where questions about signs, its relations and its

communicability are the focus. A sign is "something

that stands for something, to someone in some

capacity” (Peirce, 1931). It may be understood as a

discrete unit of meaning, and includes words,

images, gestures, scents, tastes, textures, sounds –

essentially all of the ways in which information can

be communicated as a message by any sentient,

reasoning mind to another). Semiotics is related to

the human impressions of the meaning of things in

the world, but also has the concern with the

communication (intent) held with the use of those

signs and its relations (Eco, 1976) (Chandler, 2002).

Pierce (1958) defines signs as a triad:

representation, reference and meaning. The

representation is how the sign is presented, the

reference is related to the existence of the sign at the

real world and the meaning is the interpretation

(semantic comprehension) that people built in their

minds when they are exposed to a representation of a

reference. From a semiotic perspective, it does not

make sense to mention representation without

mentioning reference and meaning do not make

sense.

One example of the application of semiotics is

the Semiotic Engineering, a research field of the

HCI (Human-Computer Interaction) area. The

Semiotic Engineering emphasizes the ability of

designers to communicate their intent through

interactive interface discourse (De Souza, 2005). In

Semiotic Engineering, a method to evaluate and

enhance interaction in software applications (the

communicability evaluation method) was developed.

Using heuristics identified at the HCI area, those

methods are used for identifying communication

ruptures so that the interface communicability can be

improved. The communication ruptures identify the

points where the interface can be improved towards

a more communicative interface (De Souza, 2005).

Applying the semiotic theory and its concern

about the communication held with the use of signs

and its relations to business models, the signs and

relations that composes those models have a

communicability feature that can be investigated and

evaluated so that the business models may be

effectively used for communication. Communication

ruptures, as defined by HCI Semiotic engineering,

may be applied to business models, those work as

the interface between the business analyst and the IT

analyst where the communication for an IS

specification can be held.

4 COMMUNICABILITY OF

BUSINESS MODELS

Applying the concept of communicability to

business models for IS specification, we define the

Communicability of a Business Model as the

capability of a business model to facilitate the

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

communication between business analyst and IT

analyst during an IS specification.

We argue that business model communicability

directly influences the ability of an IT analyst to

understand the business model as it was designed by

the business analyst. If the IT analyst understands

the business context represented by the business

model, the probability that he/she elaborates an IS

specification aligned to the business needs increases.

The need to evaluate the communicability is also

identified for business models. As the business

analyst is the designer of the communication of

business models, the messages to the IT analyst must

be evaluated, looking for communication ruptures

which can be inputs for the business model

communicability improvement.

A communication rupture of a business model is

the identification of a point in the business model,

where it was not able to communicate, or otherwise

the communication was incomplete or incorrect of

any information or understanding necessary for the

specification of the IS. Ruptures are identified

during the interaction of the IT analyst and the

business analyst through the business models.

Ruptures can be categorized into temporary and

permanent. Temporary ruptures are those solved by

the end of the interaction, either by finding some

additional information or by understanding

something that was not clear at first. Permanent

ruptures are those that remain unsolved by the end of

the interaction.

Being aware of communication ruptures, a

communicability diagnosis of business models for IS

specification can be formulated and used as the input

for improving business model communicability.

During this research, no communicability

ruptures for this context were found in literature.

Therefore, our research strategy was to perform

exploratory studies to identify an initial set of

communication ruptures, as described in the next

sections.

5 THE EXPLORATORY STUDY

An exploratory study was performed to observe and

investigate communication ruptures between IT

analyst and business analyst through the business

model, while the IT analyst tries to specify an IS.

This study domain is related to a process of real

estate management. The business context is of a

large organization that needs to manage its real state

assets, regarding tax payment; ownership

regularization, real estate documentation (like real

estate writ, environment taxes, and ownership

transfers), real estate documentation and taxes

pendency. The exploratory study scenario was

defined as follows:

 IT analyst profile – the IT analyst selected for

the study is skilled in IS specification but has

little experience on business modeling.

 The observer – the observer was an IT analyst

with business modeling experience. The

observer also had experience on

communicability evaluation related to HCI.

The observer objective was to identify and

the study.

 Tasks to perform – the IT analyst was asked to

elaborate a class diagram and a use case

specification (both in UML notation) from the

business model. The final artifacts

presentation was chosen by the IT analyst, so

it would not be a difficulty factor that could

cause false communication ruptures.

 Business model presentation – the business

model was represented in a document called

“business process book”, or simply the

“book”. The book is a document composed by

process flows, processes and activities

descriptions, elements descriptions as

documents, business rules, input/output

informations; and business terms. This

representation format was well known by the

IT analyst, so this was not a difficulty factor

that could cause false communication

ruptures.

 Business models domain – the business

models domain chosen for the study was

known by the IT analyst. The domain is

related to management of real estate assets of

an organization, treating properties

documentation, history and regularization.

 Business models types – the main models used

on the study were the eEPC (Extended Event-

Driven Process Chain), that represents the

business process workflows, and the FAD

(Function Allocation diagram) that details one

activity considering its input/output

information or artifacts, its ator and any other

relevation information (IDS Scheer, 2003).

The idea while defining the exploratory study

scenario was to prevent other factors to cause

communication ruptures during the study and

influence on the results.

5.1 Execution

The first task performed by the IT analyst was the

class diagram elaboration. The researcher asked the

IDENTIFYING RUPTURES IN BUSINESS-IT COMMUNICATION THROUGH BUSINESS MODELS

IT analyst to narrate what she was thinking while

elaborating the class diagram, so the rationale

evolved through the task execution could be also a

subject to consider on the investigation. The IT

analyst decided to draw the diagram using paper,

pencil and eraser.

The IT analyst started the task searching for the

classes that would compose the diagram. The IT

analyst narrated that she searched for domain

concepts on the business model used for the study.

She explored the business process book (the book)

looking into the process and activities names and

descriptions, trying to identify the domain concepts.

During this task, at some moments, the IT analyst

had doubts related to the domain concept’s

candidate: “Is this a domain concept for sure? What

does it mean?” This kind of questioning happened

more than once; sometimes the answer was

discovered right away by another description or

model presented in the book (“Yes, this is a domain

concept!”), but in other times the question remained

and the IT analyst decided to consider the concept as

a domain concept or not, but without confirmation of

the business model (“I’m not sure, but I think this

is it!”).

The IT analyst reported that she preferred the

textual description to the graphical one (Table 1),

due to her little experience on business modeling.

The IT analyst knew that there was a graphical

presentation of the business model, but she choose to

use the textual: “I prefer the textual description to

the graphical one because I still do not easily

understand the notation and since I know that the

textual description reflects the graphical one, I feel

more comfortable using it.”. But when she needed to

know the actors of the processes, she used the

graphical models: “It is easier to visualize!”. The

actors of the process are described by text but also

represented at the graphical model. The textual

description was an alternative way to identify the

actors. She said “No, thanks.” and used the

graphical model to get the understanding that she

needed about the process.

The IT analyst looked for relationships and

candidate methods on the process and activities

description. Some doubts related to relationships

were narrated: “What composes a real estate

history? Which are its attributes? Where is this

information? Where is it?” Looking further into the

book, she found an activity related to real estate

history analysis. By this activity description, she

found the answer for her questions about real estate

history.

While going through the descriptions, the IT

analyst noticed that there were some documents

Table 1: Textual and graphical description examples of a

business process activity (FAD – Function Allocation

Diagram).

Graphical description

Update real estate

history

Real estate

history

Real estate

administration

area

Real estate

manager

Real estate

history register

List of real

estate

pendencies

Real estate

history

Real estate

history register

Textual description

The real estate manager updates the real estate history

according to the pendency resolved.

The required information is the real estate history

(identification number of property, general plan,

specific plan, space, order, design, block, lot number of

the expropriation, the date of expropriation, housing

code, registration, name, area, width, length, value of

writing, neighborhood, owner) and the list of real estate

pendency (real estate pendency descriptions).

The generated information is the real estate history

(identification number of property, general plan,

specific plan, space, order, design, block, lot number of

the expropriation, the date of expropriation, housing

code, registration, name, area, width, length, value of

writing, neighborhood, and owner) updated.

The activity receives/ produces as input/ output the real

estate history register (containing the real estate

history).

related to the process modeled, but she was not

able to define if those documents could be treated as

a generic class. Since she did not found enough

information at the book, she decided to treat the

documents into a generic class associated to the real

estate class: “Since I cannot be sure, I will do this

way. For me, this is it.”

While still looking for the documents related to

the process, the IT analyst identified a document but

did not fully understand what that document was:

“What is it? What is a feedback document?” Then

she located the details of a feedback document on the

activity “Elaborate feedback document”. The name

of the activity helped her. She used the graphic

model to locate the activity then looked the details

on the activity description.

The IT analyst reported that some relationships

of the class diagram were defined based on the

analyst tacit knowledge of the business domain. This

was not explicit in the book.

While looking for relationships among concepts,

there were doubts about the relation among real

estate manager, real estate and real estate

pendency: “Is the property manager also

responsible for the property pendency? Is this it?”

The class diagram elaborated changed during the

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

book exploration due to new information found

while reading the book, which changed the way the

IT analyst understood concept definitions: “Oops!

This is not what I thought it was. Let me change the

diagram.

While looking for possible methods for the class

diagram, the IT analyst questioned about the

relations between class methods and activities. She

narrated that sometimes the method would have the

same name as the business activity, or some very

similar one (for example “Search for real estate

information”) but she was not sure about this

association: “What now?” How can I be sure about

this association? “She decided about some methods

for the class diagram but the question about the

association remained. At the end, to be able to finish

the class diagram, the IT analyst took some

decisions by herself: “For me, this is it.”

The analyst narrated that estate pendency and the

solution of real estate pendency seems to have a

relationship but it was not clear for her. She looked

through the book hoping to find some information

that could clarify this relationship but with no

success. So she decided to leave this relationship off

the class diagram: “I give up! I do not know if this

relationship should exist or not so I will leave it as it

is, with no relationship”.

While analyzing an activity, the IT analyst

noticed that according to the activity name, the

graphic model should be missing an element:

“Where is it?” So she looked at the activity

description and confirmed what she thought, that an

object should be represented as a product of the

activity. The graphical part of the model caused the

temporary rupture.

The analyst reached the final section of the book

where part of the elements used on the business

models is consolidated in a table with their

description. At this section are presented documents,

informations, business rules, systems and business

terms. The IT analyst used this section as reference

to define the attributes for the classes defined in the

diagram.

5.2 Discussion

The IT analyst made some inferences during the

exploratory study because she had previous

knowledge of the business domain to which the

processes were related and also because she knew

the structure of the book.

In general, the IT analyst used the textual

description as reference for elaborating the class

diagram, but the study gave an opportunity to

observe that even though she reported that she prefer

using the textual description, many times she

reported questions and rationale regarding the

graphical models. The graphical models were used

when an overall contextual understanding was

needed.

Each IT analyst might take different steps to

reach the same class diagram. Therefore, it is not

possible to predict the possible steps that an IT

analyst could follow during his interaction with the

business model. By knowing the possible steps, the

observer could question the IT analyst about other

decisions or choices that were not narrated during

the evaluation, remaining at the IT analyst tacit

knowledge. This may hide the observation of the

task execution, causing false communication

ruptures or misleading the IT analyst, hiding some

real ruptures. Another finding regards the “finish

point”. The completion of a class diagram is

subjective for each IT analyst. The parameter for

defining a class diagram as complete should be

defined by the organization, and each IT analyst

should determine what is a complete class diagram

to start an IS specification.

The communicability of business models

improvement is one resource to business and IT

alignment. The communicability feature of business

models does not eliminate other kinds of

communication between business analyst and IT

analyst. The business model communication could

be a more robust starting point for business-IT

discussions about the new IS to be specified, once

the business models communicability was addressed

since the modeling phase.

Some benefits regarding business models quality

were observed during the communicability

evaluation. While evaluating communicability, some

prospective business model quality improvements

were observed related to quality issues identified at

the business models. Other effects were related to

the prospective of evolving business model towards

an IS specification oriented model. Some IS

specification needs were not presented at the models

used as reference, the IT analyst needed to infer

about some points. If the business models represent

some IS specification needs more clearly, the

business model-IS specification process could be

benefited.

6 PRELIMINARY

COMMUNICATION

RUPTURES

Based on the exploratory study, some

IDENTIFYING RUPTURES IN BUSINESS-IT COMMUNICATION THROUGH BUSINESS MODELS

communication ruptures could be identified.

What does it mean? This kind of questioning

happened more than once; sometimes the question

was answered by looking further into the business

process book, making this communication rupture a

temporary one. But sometimes the questioning

remained and the IT analyst decided how to proceed,

making the communication rupture permanent: For

me, this is it.

No, thanks. The IT analyst was aware that there

was other option to get the information she needed,

but she chose the way that was more familiar to her

or worked better at a given situation or need.

Where is it? This communication rupture had

temporary and permanent instances. Sometimes, the

understanding needed was found looking further into

the book, or even by analyzing the graphical model,

but sometimes the IT analyst did not found what she

was looking for, and left the class diagram without

the complete information. There was one occurrence

where the graphical model caused the rupture, but

the description plus the IT analyst domain

knowledge prevented the rupture to be permanent.

For me, this is it. This communication rupture

was identified when the IT analyst decided how to

proceed without any basement of the business

process. The IT analyst made a decision by herself.

What is it? This communication rupture was

only identified as a temporary rupture. The IT

analyst found what she needed by looking further

into the book and the question was answered.

Is this it? This communication rupture was

identified a couple of times and it was a kind of

rupture that did not have a solution. It was a

permanent rupture because the book, where the

business process was present, was not able to

communicate enough to answer the question

narrated by the IT analyst.

Oops! This communication rupture presented a

“change of mind” of the IT analyst once she had

more understanding about the business process. She

defined the class diagram in a way and after getting

more knowledge from the book; she changed the

diagram according to what she had learned from it.

It was a temporary rupture, since by the time the

diagram was finished, the IT analyst had a better

understanding of the business process and was able

to change the class diagram to reflect it.

What now? This communication rupture

remained a rupture by the end of the class diagram

elaboration. The IT analyst did not know how to

proceed, making the communication rupture

permanent: For me, this is it.

I give up! This communication rupture is a very

serious one because the class diagram missed

information because of lack of communicability of

the business model.

The list of ruptures identified during the

exploratory study described above will be compared

with the list of ruptures identified on other two

exploratory studies and then the consolidate list from

the exploratory studies will be verified on study

cases using real business models.

7 CONCLUSIONS

Business models are considered a valuable

instrument through which Business-IT alignment

may be improved, and in this context the

communication between these areas is a very

important issue to address, and yet not solved in the

literature.

We define the communicability of a business

model as its capability of facilitating this

communication. To evaluate business model

communicability, this work proposes an approach,

based on the Semiotics Theory; to identify

communication ruptures in business models during

IS specification.

We conducted an exploratory study which

resulted in a preliminary list of communication

ruptures that can be used as reference to define

potential heuristics of business model

communicability. Heuristics or recommendations for

business model modeling, considering it as the

communication from business to IT, could be

defined to be used by the business analyst when

designing business model with the intent of

supporting IS specification. The communicability

concern would be addressed during the business

modeling phase, increasing the communicability

potential of business models regarding IS

specification.

Some of those ruptures were observed more the

once at the same study, which strengthens its

possibilities to really be a communication rupture

that can be generalized and used as a criteria to

evaluate business model communicability.

The issues related to the subjectivity of an IS

artifact elaboration; possible ways to elaborate and

the “finish point” of an IS artifact; need to be taken

under consideration for the following exploratory

studies to investigate if those issues can impact the

business model communicability. The IS artifact

elaboration has an interpretative factor that need to

be investigated and treated.

As future work, two more exploratory studies are

planned with different IT analysts. After those

studies, the results of the three exploratory studies

ICEIS 2010 - 12th International Conference on Enterprise Information Systems

will be compared to consolidate a set of generic

communicability heuristics that could be used to

evaluate business models for IS specification.

ACKNOWLEDGEMENTS

The authors want to thank CAPES Brazilian Funding

Agency for partially supporting this research.

REFERENCES

Barjis, J., 2008. The Importance of Business Process

Modeling in Software Systems Design. Journal of The

Science of Computer Programming, Vol. 71, N 1, pp

73-87.

Barjis, J., Augusto, J. C., Ultes-Nitsche, Ulrich, 2006.

Towards more adequate EIS, Science of Computer

Programming, Volume 65, Issue 1, Special Issue on:

Increasing Adequacy and Reliability of EIS.

Bittencourt, R., Araujo, R. M., 2008. Identificando

Expectativas de Qualidade de SIs com o apoio de

Modelos de Negócio. (Identifying IS quality needs

using Business Models) In: Workshop de Gestão de

Processos de Negócio (Brazilian Business Process

Management Workshop).In portuguese.

Chandler D., 2002. Semiotics: The Basics, Routledge.

Cruz, P. O., 2004 Heurísticas para identificação de

requisitos de sistemas de informação (Heuristics for

requirements’ identification for information systems).

Dissertation of M.Sc. NCE/UFRJ, Rio de Janeiro, RJ,

Brasil. In portuguese.

De Souza, C. S., Leitão, C. F., Prates, R. P., da Silva, E. J.,

2006. The Semiotic Inspection Method VII Brazilian

Symposium on Human Factors in Computing Systems.

De Souza, C. S., 2005. The Semiotic Engineering of

Human-Computer Interaction. Cambridge. The MIT

Press.

Eco, Umberto, 1976. A Theory of Semiotics.

Bloomington, IN: Indiana University Press/London:

Macmillan.

Ekstedt, M., Johnson, P., Plazaola, L., Silva, E., and

Vargas, N., 2005. An Organizational-Wide Approach

for Assessing Strategic Business and IT Alignment”,

Proceedings of Portland International Conference on

Management of Engineering and Technology

(PICMET05), Portland, USA.

Eriksson, H., Penker, M., 2000. Business Modeling with

UML: Business Patterns at Work. John Wiley & Sons.

IDS Scheer, 2003. ARIS Method. 2087 p.

Iendrike, H. Dos S., Araujo, R. M., 2001. Projeto de

Processos de Negócio visando a automação em BPMS

(Business Process Project towards BPMS

automation). In: Workshop Brasileiro em Gestão de

Processos de Negócio (Brazilian Business Process

Management Workshop). XIII Brazilian Symposium

on Multimedia and Web. Porto Alegre: SBC. In

Portuguese.

J. Dehnert, W. M. P., Van der Aalst., 2004. Bridging the

gap between business models and workflow

specifications, International Journal of Cooperative

Information Systems 13 (3) 289–332.

Luftman, J., Kempaiah, R., 2007. An Update on Business-

IT Alignment: “A Line” Has Been Drawn, MIS

Quarterly Executive, v. 6, n. 3.

MacKnight, D., Araújo, R. M., Borges, M.R., 2005. A

Systematic Approach for Identifying System

Requirements from the Organizationan Business

Model, In II Brazilian Symposium on Information

Systems.

Marques, C., and Sousa, P., 2003. Getting into the

misalignment between Business and information

Systems”, The 10th European Conference on

Information Technology Evaluation, Madrid, Spain.

Peirce, Charles Sanders, 1931-58. Collected Writings (8

Vols.). (Ed. Charles Hartshorne, Paul Weiss & Arthur

W Burks). Cambridge, MA: Harvard University Press

Plazaola, L., Silva, E., Vargas, N., Flores, J., Ekstedt, M.,

2006. A Metamodel for Strategic Business and IT

Alignment Assessment, Conference on Systems

Engineering Research, University of Southern

California, USA..

Sharp, A., Mcdermott, P., 2008. Workflow Modeling:

Tools for Process Improvement and Application

Development. Norwood: Artech House. ISBN: 1-

58053-021-4. 345 p.

Yu, E., 1995. Models for supporting the redesign of

Organizational Work. In Proceedings of Conference

On Organizational Computing Systems (COOCS’95),

225-236.

IDENTIFYING RUPTURES IN BUSINESS-IT COMMUNICATION THROUGH BUSINESS MODELS