Structuring Software Cities – A Multidimensional Approach
Andreas Hess, Bernhard Humm1, Markus Voss, Gregor Engels2
sd&m Research, Munich, Germany,
1
additionally Darmstadt University of Applied Sciences, 2additionally University of Paderborn
{Andreas.Hess, Bernhard.Humm, Markus.Voss, Gregor.Engels}@sdm.de
Abstract
Software cities alias application landscapes of large
enterprises comprise tens or even hundreds of IT
applications. Structuring software cities into domains
is an important task of enterprise architects. The
quality of the resulting domain model is crucial for the
success of enterprise architecture management and an
important tool for the governance of the development
of an enterprise’s application landscape. This paper
presents a novel method for constructing domain
models based on business services, business objects,
and business dimensions. The method has been
validated in numerous industrial projects.
to group the applications. In this paper these coloured
zones of an application landscape are called domains.
They define a high level structure for the application
landscape – the domain model – that can be used as a
tool in enterprise IT architecture management. In this
paper, we present a method for constructing domain
models for application landscapes. This method uses
multiple dimensions (customers / markets, products,
length of value chain, access channels to customers) to
deduce the domains. This method has been proven in
industrial practice.
1. Introduction
The IT departments of large enterprises today run tens
or even hundreds of IT applications. All applications,
together with their interconnectivity, we call the
application landscape of the enterprise. Application
landscapes are sometimes also called software cities. If
one compares the architecture of an individual
application with the architecture of a building then the
architecture of an application landscape is like the
structure of a city. Like real cities, software cities need
city planning to provide high quality support for the
enterprise’s business processes and flexible
adaptability to changes in the enterprise’s ecosystem.
Software city planning is the task of enterprise IT
architects. As a discipline, enterprise architecture
management addresses the structure of an application
landscape (software city) as well as the management
processes needed to govern the development of an
application landscape from an as-is situation to a target
structure.
Figure 1 shows the application landscape of a bank
as an example. It shows the applications as components
of the application landscape with their dependencies. It
also shows a base structure (the coloured boxes) used
Figure 1. Domain model and IT components of
a bank
This work is part of the research effort Quasar
Enterprise which has been conducted at sd&m
Research and sd&m IT Consulting for more than three
years. Quasar Enterprise distils the experience from
enterprise architecture management and systems
integration in numerous industrial projects with a total
effort of more than 100 person years.
The paper is structured as follows: in Section 2, we
introduce domain models. Section 3 defines the input
for the method for constructing a domain model. This
method is then presented in Section 4. Section 5 gives
an example, followed by project experience (Section 6)
Andreas Hess, Bernhard Humm, Markus Voß, Gregor Engels
Structuring Software Cities - A Multidimensional Approach
Proceedings of the 11th IEEE International EDOC Enterprise Computing Conference (EDOC 2007)
ISBN 0-7695-2891-0, IEEE Press, 2007
and related work (Section 7). Section 8 concludes this
paper.
2. Application Landscapes and Domains
2.1 Terminology
Domains are the districts and suburbs of software
cities. We use the term domain knowing that (like
component) it is heavily used in different contexts with
various meanings (e.g. domains in data modelling,
domain specific languages, domains in component
models like .NET, or business domains like banking).
We chose to stick to it since it is widely established in
the enterprise architects’ community [1], [2], [3].
The terms software city and application landscape
are often used in publications on enterprise architecture
as synonymous metaphors for the structure of an
enterprise’s IT application portfolio. Examples are [4]
and [5]. For the rest of this paper, we will use the term
application landscape.
Domains represent clusters of services and managed
information. They provide the top level structure of the
application landscape. Domains may be refined by sub
domains. In Figure 1, the domains are represented by
the differently shaded areas of the application
landscape. Domains group logical components which
are bundles of services – the white boxes in Figure 1.
The logical components are implemented using
physical applications (commercial off-the-shelf or
custom-built) that are integrated using an appropriate
integration infrastructure, e.g. an enterprise service bus
(ESB). The structure of the domains forms the domain
model of the enterprise. Depending on the industry and
the individual enterprise a domain model typically
consists of approximately 10 - 30 top-level domains.
In this paper, we do not address groups of
application landscapes, which would be a possible
option for enterprise architecture management for
multinational corporate groups.
We also focus on the top-level domain structure
only. Domain / sub domain structures and component /
subcomponent structures are possible. The presented
method applies accordingly for different levels of
granularity.
2.2 Why is a domain model important?
Domain models can be used by enterprise architects as
a tool for defining the target application landscape at
the enterprise level. Large Enterprises like Credit
Suisse [1] or Deutsche Post [2] follow the strategy of a
managed evolution of their application landscapes
from an as-is situation to defined target. The managed
evolution approach aims to define smaller IT projects
with positive business cases and limited scope, so as to
provide short-term business benefits while complying
with a standard target.
The evolution is managed, because enterprise
architects govern the development of the application
landscape. In this way domain models are used for
strategic planning as well as for the operational
management of an enterprise’s IT project portfolio.
A domain model also helps to establish business
ownership for applications and services as it links the
business process architecture and the IT application
architecture of an enterprise: domains represent sets of
applications and databases that are managed as units
for business reasons, instead of organizing them, e.g.,
by types of IT platforms.
Documenting application landscapes, another central
part of enterprise architecture management, relies
heavily on graphical and intuitive visualizations.
Planning, deciding, and controlling with respect to
measures on the application landscape all benefit from
such visualizations, called software maps [6], [7].
Similar to the concept of maps used in cartography, a
software map is composed of a base map and several
layers. Figure 1 is an example of such a software map.
Based on a defined domain structure, software maps
can be used to visualize the delta between an as-is
situation and the target situation defined by the domain
model: The target domain model is used as a base map
together with a mapping of the as-is application
components on an individual layer.
Domains can also be helpful for more technical
aspects of architecture management as they provide the
starting point for the definition of rules for
• the design of components, e.g., components must
not span domain boundaries
• the design of interfaces, e.g., loose coupling for
interfaces used across domain boundaries
• the use of technologies for application integration,
e.g. mandatory use of an enterprise service bus for
the integration of components in different domains
3. Required input for constructing a
domain model
The method for constructing a domain model deduces
the domains from a set of input parameters that are part
of the enterprise’s operating model.
sales & advice, operations (production), and support
service.
3.1 Business services
Application landscapes are structured according to the
business of an enterprise – not according to technology.
Hence, the most important inputs for modelling
domains are the business services of the enterprise. By
business services we understand a top-level grouping of
the main business activities that can be found in the
value chain of an enterprise. Identifying business
services is the task of business analysts. They can be
derived from the top level business processes and the
enterprise’s organization.
We distinguish between core business services and
management & support services. Core business
services directly facilitate the business strategy of an
enterprise whereas support services only indirectly
facilitate it. Business services can be structured
hierarchically. We aim at about 5-10 top-level core
business services. Figure 2 shows typical business
services of a bank.
Marketing
Sales
& Advice
Operations
Support
Service
Order
Management
Order
Execution
Settlement
Custody
Accounting
Controlling
Risk
Management
Human
Resources
Top-level business objects are coarse-grained. We aim
at about 5-10 business objects.
Compliance
Product
Contract
Order
Account
Figure 3. Business objects
Accounting
& Booking
Management &
Support Services
ERP
Business objects are the most relevant top-level
information items of an enterprise. In our banking
example we identify the following:
• Business Partner, e.g., a retail banking customer
• Product, e.g., savings, checking accounts, loans
• Account, e.g., the account used for booking of
payments
• Contract, e.g., the result of opening a checking
account
• Order, e.g., a bank transfer from one account to
another
Business
Partner
Core Business
services
Product
Development
3.2 Business objects
Treasury
…
Identifying the main business objects and is the
business analysts’ task. As for business services,
similarly named business objects are used in different
businesses. For example, an automotive manufacturer
also has business partners, products, contracts, and
orders.
…
Figure 2. Business services of a bank
(examples)
A bank comprises the following core business services:
• Product development, e.g., the development of new
products and services
• Marketing, e.g., performing campaigns
• Sales & advice, e.g., advising retail customers on
home loans
• Operations, e.g., selling stocks on the stock
exchange (order execution)
• Support service, e.g., sending monthly account
statements to customers
Management & support services are classic enterprise
resource planning services (e.g., accounting,
controlling, human resources), as well as risk
management, compliance, treasury etc.
Since business services are top-level and coarsegrained, they are similar for different businesses. For
example, an automotive manufacturer also performs the
business services of product development, marketing,
3.3 Business dimensions
The operating model of an enterprise is typically
shaped by the following question: Which products are
sold to which customers / markets using an how long is
the enterprise’s value chain?
A bank may answer this question in the following
way. The portfolio comprises the following products:
• Account-based products, e.g., savings bank accounts
• Loans, e.g., home loans
• Securities, e.g., stocks, bonds
• Payments, e.g., bank transfers
Products are sold to the following customers / markets:
• Retail banking customers, i.e., private customers
• Corporate customers, i.e., companies
The following value-creating operations are / are not
carried out by the enterprise:
• Product development, marketing, sales, and support
service are completely performed within the
enterprise.
• Payment transaction banking is not performed
within the enterprise but is being outsourced to a
partner corporation.
• Credit administration and securities settlement and
custody are candidates for possible process
outsourcing in the future. Both are subtasks of
operations.
Often in this context, the term business value creation
chain or shortly value chain is being used. The length
of the value chain defines which value-creating
operations are carried out within enterprise itself and
which are carried out by partners. The more tasks are
performed within the enterprise the longer the value
chain. The more tasks are outsourced to partners the
shorter the value chain. Modern enterprises tend to
shorten the value chain by concentrating on their core
business and by outsourcing specific tasks to
specialists.
Categories like products, customers / markets or
length of the value chain we call business dimensions.
See Figure 4 for the banking example.
…
Customers /
Markets
• Retail
banking
customers
• Corporate
customers
Products
• Branch
• Self-service
• E-banking
• Call
Centre
Customer Access
Channels
• Account-based products
• Loans
• Securities
• Payments
(depending on business service)
Length of
Value Chain
Figure 4. Business dimensions of a bank
The dimensions customers / markets, products and
length of value chain are relevant to most businesses.
Additionally, there may be business-specific
dimensions. For a bank, the following customer access
channels may be relevant:
• Branch, i.e. agencies where clerks directly service
customers face-to-face
• Self-service, e.g. automatic teller machines
• E-banking, i.e. offering banking products via
internet portals
• Call-centre, where clerks service customers via
telephone
Again, identifying the relevant business dimensions and
their values is the task of a business analyst. We aim at
about 3-5 business dimensions with about 2-5 values
each. The values of the dimensions are directly linked
to the business strategy of the enterprise. E.g., a direct
bank’s strategy is to focus solely on the customer
access channels e-banking and call centre.
Business services, business objects and business
dimensions of the operating model form the input
parameters for our method to deduce the domains. It is
presented in the next chapter.
4. A method for constructing a domain
model
Structuring application landscapes by domains is the
task of enterprise IT architects. Finding a domain
model of high quality is crucial for enterprise IT
architecture management. It requires a high level of
expertise, both in the business and in domain
modelling. Constructing a domain model in practice is
a highly incremental process. It is top-down from the
business strategy as well as bottom-up from the
existing application landscape. It requires a lot of
communication and alignment since the final domains
and their names must be understood and used by
numerous stakeholders.
Insofar, there cannot be a method for constructing a
domain model which can be applied mechanically and
in an uninformed manner which nevertheless leads to a
domain model of high quality. However, the experience
from numerous domain modelling projects shows that
there are common patterns, particularly in the top-down
driven parts of the process – the bottom-up driven parts
are usually specific to the application landscape under
consideration. The following method for constructing
domain models comprises those patterns in form of
concrete steps.
The input for this method comes from business
analysts as described in the last chapter:
• Business services, divided between core business
services and management & support services
• Business objects and their associations with business
services
• Business dimensions and their values according to
the business strategy
Given this input, the method is as follows.
1. Core business services: Take the top-level core
business services as initial domain candidates.
2. Business dimensions: Split domain candidates
according to the characteristics of one or more
business dimensions if their handling substantially
differs from a business point of view. Iterate this
step as long as the business strategy demands further
differentiation.
3. Business objects: Consider the top-level business
objects. In which of the domain candidates are they
being written, i.e., generated, modified, or deleted?
Make new domain candidates for all business
objects that are being written in more than one of the
existing domain candidates.
4. Management & support services: Make domain
candidates for all management & support services.
They usually follow the structure of modules that
enterprise resource planning (ERP) software uses.
5. Finalize: The domain candidates become the final
domains. Find meaningful domain names that are
understood and accepted throughout the enterprise –
if not already done during the iterations. Find a
meaningful and intuitive graphical representation of
the domain model. Check for completeness of the
model by mapping the physical as-is applications to
the domains.
Sales
& Advice
Business dimension customers / markets
Retail banking customers
Corporate customers
Corporate
Retail Banking
Banking
(sales & advice for
(sales & advice for
retail banking
corporate
customers)
customers)
Figure 6. Splitting sales & advice according to
customers / markets
The business service support service differs according
to the business dimension customer access channels.
The resulting domain candidates are named branch
systems, self-service, e-banking, and call centre. See
Figure 7.
Support Service
Business dimension customer access channel
Branch
E-banking
Self-service
Call centre
5. Example
We demonstrate the method for constructing a domain
model using the bank example.
Branch
Applications
(Support service
via branch)
Step 1: Core business services
Figure 7. Splitting support service according
to customer access channels
In the first step, the top-level core business services
form the initial domain candidates. See Figure 5.
Product
Development
Marketing
Sales
& Advice
Operations
Self-Service
(Support service
via self-service
facilities)
E-Banking
(Support services
via e-banking)
Call Centre
(Support service
via call centre)
Additionally, the business service operations differs
according to both business dimensions value chain and
product. See Figure 8.
Support
Service
Business dimension length of value chain
Figure 5. Core business services
Operations
Order
Management
Order
Execution
Settlement
Custody
Accounting
& Booking
The second step is the most difficult step since it
requires fundamental knowledge of the business
strategy of the enterprise.
According to the business strategy of the bank, the
business service sales & advice is to be performed
differently along the business dimension customers /
markets, e.g., for retail banking customers and for
corporate customers. Therefore, the domain candidate
sales & advice is split into two domains. The resulting
domain candidates are named retail banking and
corporate banking. See Figure 6.
Business dimension product
Step 2: Business dimensions
Accountbased
products
Core banking
(Order management, order execution, settlement, and custody for
account-based products)
Loans
Credit Approval
(Order management and order
execution for loans)
Credit Administration
(Settlement and custody for loans)
Securities
Securities Trading
(Order management and order
execution for securities)
Securities Custody
(Settlement and custody for
securities)
Payments
Payments Order
Management
(o.m. for payments)
Accounting &
Booking
(Accounting and
booking for all
products)
Payment Transaction
(Order execution, settlement and custody for
payments)
Figure 8. Splitting operations according to
product and length of value chain
The business service operations differs substantially
for the different products and therefore different
horizontal domain candidates are introduced. However,
accounting & booking can be treated identically for all
products. Therefore, one vertical domain candidate is
being introduced. The split of the execution of
payments along the value chain is motivated by the
business strategy to outsource the payment transaction
banking to a partner corporation. For similar reasons
the value chains for loans and securities are each split
into two domains.
during the iterations. Figure 12 shows the final domain
model.
Branch
Applications
Customer-facing
domains
In this step, new domain candidates are being
introduced for business objects that are written (i.e.,
generated, modified, or deleted) in more than one of
the existing domains. For example, business partners
are being written in branch applications, e-banking
and in call centre applications. So, the new domain
candidates business partner management, contract
management, and account management are introduced.
See Figure 9.
Order
Management
(handling order
business objects)
Account
Management
(handling account
business objects)
Figure 9. New domain candidates for business
objects
The business object product is being read in most
domain candidates, including branch applications, self
service, e-banking, and call centre. However, it is
written in the domain candidate product development
only. Therefore, both aspects – the business service
product development and the management of the
business object product – are assigned to the same
domain candidate, which is simply named product. See
Figure 10.
Product
(product
development and
handling product
business objects)
Figure 10. Domain candidate product
Step 4: Management & support services
The management and support services become domain
candidates. See Figure 11.
Compliance
Call Centre
Retail Banking
Core
business
ERP
E-Banking
Core Banking
Step 3: Business objects
Business Partner
Contract
Management
Management
(handling business (handling contract
partner objects)
business objects)
Self Service
Treasury
Risk
Management
…
Figure 11. Domains for management & support
services
Step 5: Finalize
The domain candidates identified so far become the
final domains. Meaningful names have been found
Product
Management
& Support
Business Partner
Management
ERP
Credit
Administration
Securities
Trading
Securities
Custody
Payments Order
Management
Payment
Transaction
Marketing
Corporate
Banking
Enterprise
Resources
Credit Approval
Contract
Management
Compliance
Order
Management
Treasury
Accounting &
Booking
Account
Management
Risk Management
…
Figure 12. Final domain model
The final domain model shows customer-facing
domains at the top of the diagram. The centre shows
domains for the core business services, along the value
chain. Then, domains managing enterprise resources
are listed. At the bottom of the diagram, domains for
management & support services are shown.
6. Project experience
sd&m has analyzed and / or constructed over 20
application landscapes of large corporations of
different industry sectors. In some of those projects, the
method for constructing the domain model has been
applied explicitly, in others implicitly. We have
analyzed 18 of the resulting domain models according
to the usage of business services, business objects, and
business dimensions.
The analysis demonstrates convincingly that
business services, business objects, and business
dimensions play an important role and, hence, give
evidence of the validity of the method described.
Table 1 gives an overview of sample domain names
from nine application landscapes in the industry sectors
automotive,
banking,
insurance,
public,
telecommunication, and tourism.
Table 1. Selected domains from application
landscapes in different industry sectors
Industry
Business
Business Value chain Customers,
sector
functions
objects
markets
Automotive • Supply
• Order
• Order
Mgmt
• Production
• Logistics
Banking
• Advice
• Customer • Securities
outsrc.
• Sales
• Product
• Account
Banking
• Support
• Business • Payment • Retail
service
partner
TXN customers
central
• Operations
• Corporate
bank
customers
Banking
• Order
• Retail
• all are split • Partner
mgmt.
• Private
• Securities • Corporate
settlement
• Credit
approval
• Credit
admin.
Life
• Product
• Contract
Insurance
devel.
mgmt.
• Acquisition • Claims
& advice • Customer
• Conclusion mgmt.
• Payments
Insurance • Service
• Contract
• Analysis • Partner
Public
Telecommunication
Tourism
• Customer
care &
advice
• Cash
benefit
• Sales &
marketing
• Invoicing
• Product
mgmt &
design
• Booking
• File mgmt.
• Personal
data mgmt.
• Supplier &
partner
• Customer
• Contract &
resource
mgmt.
Products
• Passenger
cars
• Trucks
• Bus
Channels Management
& support
• Quality
mgmt
• Finance &
controlling
• Loans
• Customer
& bank
• Payments
frontends
• Investment • Branch
banking
mgmgt
• Financing • Customer
interaction
• Account
products
• Complex
credits
• Accounting
• Controlling
• Bank
mgmt.
• Regulatory
reporting
• Risk
controlling
• Market
data supply
• Life
insurance
• Financing
• Sales
mgmt.
• Life
insurance
• Property
insurance
• Monetary • Customer
service
channels
(face-to• Programs
face,
phone, …)
• Office
comm..
• Planning
• Personnel
• Administrative
services
• Business
• Multichannel
services
• Monitoring
& ERP
7. Related work
There is not much work known to the authors that
addresses concrete methods for domain modelling in
application landscapes.
Approaches to service oriented modelling of
architecture like [8] describe domain decomposition as
an important step for the identification of services, but
confine themselves to stating that a combination of topdown, bottom-up, and middle-out techniques must be
applied.
In [9], Ambler et al. describe an extension of the
Rational Unified Process for enterprise architecture
that treats Enterprise Domain Modelling as a subtask
of the discipline Enterprise Business Modelling
distinguished from the Enterprise Architecture
discipline. In [10], Ambler suggests that for some
organizations it might be fine to combine both
disciplines in “a domain engineering approach where
high-level domain concepts are implemented in a
reusable manner, perhaps as domain components or
collections of web services. This approach requires
significant sophistication within your organization,
including a strong approach to enterprise business
modelling as well as to enterprise architecture. Domain
engineering represents the pinnacle of strategic reuse.”
In his article “A methodology for service
architectures”, Jones comes close to the methodology
we describe [11]. He also starts out with business
services. Since his article focuses on the identification
of services, the succeeding refinement steps differ from
our method for identifying domains.
Fundamental works on the separation of concerns
and modularization like, e.g., [12] are, as a matter of
course, the basis of our method. Particularly the works
of Parnas (e.g., [13], [14]) have laid out the basics for
designing components in the small. Our method can be
seen as an application of Parnas’ principles in the large.
Our approach has similarities with different forms of
organizational structures of enterprises, e.g. matrix
organizations that combine functional and divisional
structures where divisions are defined by products,
markets or customer groups.
8. Conclusion
Application landscapes are extremely complex. One
important tool of enterprise architecture management is
structuring them into domains. Domains are being used
for strategic planning as well as for the operational
management of an enterprise’s IT project portfolio –
the driver for the evolution of the application
landscape. Because of this, a domain model of high
quality is crucial.
In this paper, we have presented a method for
constructing a domain model. The method takes into
account business services, business objects and
business dimensions like customer groups, product
groups / markets, customer access channels and the
length of the value chain. The main contribution of this
paper is a concise description of the method in five
steps which cannot be found in literature so far.
However, the method is based on well-known
architecture principles and has already been used
successfully in numerous large-scale industrial projects.
Although the method is relatively straight-forward, a
high degree of business expertise and modelling
experience is still required when constructing domain
models of high quality.
9. References
[1]
[2]
Anella, M., Strategy & Architecture, 2. Berner
Architekten Treffen (2005), http://www.bernerarchitekten-treffen.ch/archiv/2/CS_2005-11-11%20%20BAT-Vortrag.pdf
Deb M., Helbig J., Kroll M., Scherdin A., Bringing
SOA to Life: The Art and Science of Service Discovery
and
Design,
http://webservices.syscon.com/read/164560_p.htm,
also
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
http://www.oracle.com/events/architectforum/art-andscience-of-service-discovery_032206.pdf
J. Laartz, E. Monnoyer, A. Scherdin: Designing IT for
business,
The
McKinsey
Quarterly
3/2003,
http://www.mckinseyquarterly.com/links/13022
J. Laartz, E. Sonderegger, J. Winckler: The Paris guide
to IT architecture, The McKinsey Quarterly 3/2000,
http://www.mckinseyquarterly.com/links/4037
Keller W.: Managing Application Portfolios in Merger
Situations, in: Dadam P., Reichert, M. [eds.]:
INFORMATIK 2004 - Informatik verbindet, Band 1,
Beiträge der 34. Jahrestagung der Gesellschaft für
Informatik
e.V.
(GI),
http://www.objectarchitects.de/ObjectArchitects/papers
/Published/ZippedPapers/GIWK2004-06-13a.pdf
Lankes,
J.,
Matthes,
F.,
Wittenburg,
A.:
Softwarekartographie: Systematische Darstellung von
Anwendungslandschaften. In: Wirtschaftsinformatik
2005,
Bamberg,
2005,
http://wwwmatthes.in.tum.de/file/Publikationen/2005/L
MW05a/041005-LaMaWi-WI2005-Paper.pdf
Ernst, A., Lankes, J., Schweda, C., Wittenburg, A.:
Using Model Transformation for Generating
Visualizations from Repository Contents - An
Application to Software Cartography. Technische
Universität München, Institut für Informatik, Lehrstuhl
für Informatik 19, Technischer Bericht TB0601, 2006,
http://wwwmatthes.in.tum.de/file/Publikationen/2006/E
r06b/Er06b.pdf
Arsanjani, A.: Service-oriented modeling and
architecture, IBM DeveloperWorks, SOA and Web
Services,
http://www128.ibm.com/developerworks/webservices/library/wssoa-design1/
Ambler, S. W., Nalbone, J., Vizdos, M. J., The
Enterprise Unified Process: Extending the Rational
Unified Process, Pearson Education (2005)
Ambler, S. W.: Extending the RUP with the Enterprise
Business
Modeling
Discipline.
http://www.enterpriseunifiedprocess.com/essays/enterp
riseBusinessModeling.html
Jones, S.: A methodology for service architectures.
Capgemini
white
paper,
http://www.oasisopen.org/committees/download.php/15071/A%20meth
odology%20for%20Service%20Architectures%201%2
02%204%20-%20OASIS%20Contribution.pdf
Ghezzi, C., Jazayeri, M., Mandrioli, D.: Fundamentals
of Software Engineering. Prentice Hall (1991)
Parnas, D.L.: On the Criteria To Be Used in
Decomposing Systems into Modules, Communications
of the ACM 15(12), 1053–1058 (1972)
Parnas, D.L.: Designing software for ease of extension
and contraction, IEEE Transactions on Software
Engineering 5(2), 128–138 (1979)