Features
Architect’s Spotlight: Alice Cave 4
Architect’s Toolkit: Review of No Magic® MagicDraw™ with 6 DoDAF Plug-in: Lawrence McCaskill and Ian Komorowski
Articles
An Information Model for Managed 12
Application Landscape Evolution
Sabine Buckl, Alexander M. Ernst, Florian Matthes, Christian M. Schweda Process-Centric Enterprise Architecture 27 Paul Stamas
A Contingency Approach to 36
Enterprise Architecture Method Engineering Christian Riege and Stephan Aier
Case Study
Using Metamodels to Improve Enterprise Architecture 49 Lyn Uzzle
February 2009 | Volume 5, Number 1
The Journal of Enterprise Architecture
February 2009
Volume 5, Number 1
Features
a|EA Points of Contact 3
Architect’s Spotlight: Alice Cave 4
Architect’s Toolkit: Review of No Magic® MagicDraw™ with 6 DoDAF Plug-in: Lawrence McCaskill and Ian Komorowski
Articles
An Information Model for Managed 12
Application Landscape Evolution
Sabine Buckl, Alexander M. Ernst, Florian Matthes, Christian M. Schweda
Process-Centric Enterprise Architecture 27 Paul Stamas
A Contingency Approach to 36
Enterprise Architecture Method Engineering Christian Riege and Stephan Aier
Case Study
Using Metamodels to Improve Enterprise Architecture 49
Lyn Uzzle
International Executive Committee President: John Gøtze
Vice President: Gary Doucet
Secretary: Kristian Hjort-Madsen Treasurer: Scott Bernard
General Member: Richard Burk [email protected]
General Member: Mike Lowe National Chapters
Australia Chapter Levine Naidoo
Canada Chapter Mike Giovinazzo [email protected]
Chile Chapter Alfredo Piquer [email protected]
Colombia Chapter Francisco Ballesteros
Denmark Chapter John Gotze
German/Swiss/Austria Chapter Mike Alter
India Chapter Sunil Dutt Jha
Ireland Chapter Joe McGouran
Korea Chapter John Kang [email protected]
New Zealand Chapter Mike Lowe
South Africa Chapter Graham McLeod [email protected] Taiwan Chapter Cathy Sung
United Kingdom Chapter John Good
[email protected] United States - Local Chapters Atlanta Chapter
Andrew LeBlanc
[email protected] Dallas / Fort Worth Chapter William Krauter
Delaware Valley Chapter Michael Robison
California Chapter
Walter Wilson
New York Chapter Brian Clark
San Antonio Chapter Orvis Meador
Seattle Chapter
Marci Hadnot
Tampa Chapter
Liesel Muth
Washington DC Metro Chapter Margaret James
a|EA Points of Contact
Alice Cave
JEA has often featured pioneers and senior architect’s in the spotlight, but this quarter's featured architect is Alice Cave who was chosen to because she represents a practitioner who is relatively new to the field. Alice began working in the field of Enterprise Architecture in 2006 on a multi-year project to complete the third comprehensive update of the Enterprise Architecture at the Federal Railroad Administration in Washington DC, which is part of the U.S. Department of Transportation.
Though Alice is new to the EA field, she has nearly thirty years of experience in Federal Government IT consulting. Before joining Citizant, she worked with SAIC, Systems Center (now part of Computer Associates), Acton Burnell, and CACI. Over the years, Alice’s consulting engagements have allowed her to work with a number of federal agencies, including the Department of Veterans Affairs, the Department of Transportation, the U.S. House of Representatives, the U.S. Army (Reserve Component), and the Department of State in their Office of Data Management. Alice graduated from Gettysburg College with a BA in English and currently lives in Alexandria, VA.
JEA: How did you become involved in the field of Enterprise Architecture?
Cave: The field of Enterprise Architecture found me when I joined Citizant, Inc. An emerging leader in the EA practice area, Citizant is a company that has a very effective hiring process which allows the company to recruit potential architects from other areas – people like me who are involved in other fields but who have skills that lend themselves readily to EA. Once I was involved in EA, I was immediately struck by how much sense it made. It provides a real opportunity to marry business needs with information technology decisions, and to prevent needless IT spending. I can really appreciate the value of this after years of requirements analysis, and representing the end user as a technical writer.
JEA: What aspect of information technology did you work in prior to becoming involved with Enterprise Architecture?
Cave: I graduated from Gettysburg College with a degree in English. I won’t mention the year, but it was before the PC was invented. Obviously, there have been many changes since that time! As the field of IT took off, I took my experience from various editorial jobs and became a technical writer. Working in a small consulting firm in the early 1990s, I discovered data modeling, database design, and systems/requirements analysis. So, I come to the EA field mainly from the perspective of business requirements and data management, and for me it was a natural transition, since I have a lot of experience representing business needs from various perspectives.
JEA: What do you think are the important issues that the field of Enterprise Architecture should be currently addressing?
Cave: I think that the issue of representing business needs in IT decisions will always be important. In my years of experience, I have seen so many instances of managers becoming enamored with new and interesting technologies, and they try to find ways to bend their business to use the technology, rather than analyzing their business needs first. This is a cultural issue to deal with after years of IT dominance in decision-making. I work in EA in the Federal Government area, and Federal agencies have to look closely at their IT spending in order to be compliant with the Office of Management and Budget (OMB) and other regulations. The practice of EA offers great potential for addressing this issue by bringing business experts into IT decisions.
JEA: Do you feel that the field of Enterprise Architecture is open to women practitioners and thought leaders?
Cave: While the IT field has been traditionally male-dominated, I do believe that EA offers a chance to truly diversify the voices represented in the field of information technology. EA brings
Architect’s Spotlight
together business leaders who develop strategy for their organizations, the managers and workers who implement the strategy, and the managers and practitioners of information technology. This is a wide variety of perspectives and talents that can be applied to solving difficult business problems.
JEA: Are there any special difficulties that women face in the field of Enterprise Architecture?
Cave: Maybe I am missing something, but I have not noticed any!
JEA: What was your most favorite Enterprise Architecture project, and why was it the favorite?
Cave: Since I’m relatively new to the field, my favorite project is my first project, the one I work on now. As a member of the Federal Railroad Administration (FRA) EA Team, I have had the opportunity to work with Adel Harris, Tanaia Parker, and other great practitioners. Right now we are finishing a project to document the entire FRA architecture, segment by segment, and in doing so I have had to dive deep into the core
mission functions of FRA. I have focused on data modeling and business modeling, and it has been great to learn all about trains and train safety, and to use EA to provide valuable recommendations that, if implemented, could play a part in enhancing railroad safety. As a bonus (to a data geek like me) we worked with Dr. Richard Wang of MIT on a data quality pilot project to resolve some of FRA’s data “pain points.”
JEA: What was your least favorite Enterprise Architecture project, and why was it the least favorite?
Cave: I don’t have a good answer for this one because FRA is my only EA project thus far.
JEA: What advice would you give to someone entering the field of Enterprise Architecture?
Cave: I think the field of Enterprise Architecture is a great choice for someone who has at least a few years of experience either in IT or on the business side (or both), just to provide a sense of perspective.
Call for Papers
The Journal of Enterprise Architecture
is accepting article submissions for its 2009-2010 issues Research and best practice articles
are sought on EA-related topics, including:
Case Studies, Configuration Management, Culture, Documentation, Evaluation, Frameworks, Governance, Implementation, Maintenance,
Methodologies, Taxonomies, Theory, Training, Tools, Use, Value
Send articles to the JEA Editor
Issue Due Date
February November 1
May February 1
August May 1
November August 1
Author submission guidelines can be found on the a|EA website at
Review of No Magic® MagicDraw™ with DoDAF Plug-in
By Lawrence McCaskill and Ian Komorowski
INTRODUCTION
In previous Architect’s Toolbox articles we have described three basic categories of software tools that fall into the EA domain-precision (focusing on a particular subset of EA), all-in- one (can capture all of the elements needed for a complete EA), and repository management (focused on the analysis of EA data). No Magic’s MagicDraw is an “all-in-one” tool specifically focused on a Unified Modeling Language (UML) implementation of the Department of Defense Architecture Framework (DoDAF). It supports DoDAF V1.5, and will likely support the DoDAF 2.0 and the UML Profile for DoDAF and MODAF (Ministry of Defence Architecture Framework (UPDM – see:
after these standards are released.
The core MagicDraw enterprise tool is a business process, architecture, software and system modeling tool designed facilitate end-to- end analysis and design of Object Oriented (OO) systems and databases. Its target users include: Business Analysts, Software Analysts, Programmers, QA Engineers, and Documentation Writers. It provides full round- trip support for Java, C++, C#, CL (MSIL) and CORBA IDL programming languages, as well as database schema modeling, DDL generation and reverse engineering facilities. Using MagicDraw’s Teamwork Server, multiple developers can work simultaneously on the same model. It interfaces with another No Magic tool called Cameo SUITE, which appears to provide a means of managing requirements via linking objects (documents, models, etc.), much in the way IBM® Telelogic® DOORS® or IBM Rational® RequisitePro® allow for requirements management.
The DoDAF plug-in supports all work products and views in the DoDAF specification (A complete description of the DoD Architecture Framework can be found here:
an extension of MagicDraw’s SysML plug-in, and thus, in addition to the DoDAF products, allows creation of the entire list of System Modeling Language (SysML) diagrams, as well as the ability to use the Business Process Modeling Notation (BPMN), which DoDAF practitioners often use in lieu of an Event Trace diagram in the creation of the DoDAF OV-6c Operational Event/Trace work product.
The product evaluated was the downloadable evaluation copy of No Magic MagicDraw Enterprise V16.0 with SysML and DoDAF plug- ins (the DoDAF plug-in requires installation of the SysML plug-in). This review will focus on MagicDraw from the perspective of being able to develop DoDAF architectures in support of the Joint Capabilities Integration and Development System (JCIDS) architectures, which the DoD uses to show how individual platforms (airplanes, ships, ground vehicles) fit into the overall scheme of things from an information technology perspective.
INS TAL L ATION AND S E TUP
Installation for the MagicDraw Enterprise tool and the SysML and DoDAF plug-ins required about 380MB disk space. The MagicDraw web site recommends a Pentium™ 4 1.4GHz and 1GB RAM for NT/2000, and 2GB RAM for Windows Vista. Other operating systems supported included Linux and Mac OS X. We used Lenovo T61p Thinkpads with 3GB RAM for the evaluation.
Installation was relatively straightforward: install the core MagicDraw tool, then unzip the SysML and DoDAF plug-ins into the “MagicDraw UML”
directory (under Program Files). Unlock keys for the core MagicDraw product as well as the SysML and DoDAF plug-ins had to be placed on the hard drive (I put them in the “MagicDraw UML” directory. The e-mails automatically sent to the registered user upon downloading the plug-ins and containing the keys explained the
Architect’s Toolbox
process reasonably well. The software looked for these keys upon loading, and once pointed to the file locations never asked for them again.
One issue with the free demo download – it only allowed for 20 classes to be created, which were all used by the DoDAF plug-in upon startup to stereotype different classes as different diagram/object types in DoDAF. A call and an e-mail to No Magic solved the problem via updated unlock keys. We suspect that this may be “on purpose” to force engagement with the No Magic sales staff.
INS TAL L ATION AND S E TUP
Installation for the MagicDraw Enterprise tool and the SysML and DoDAF plug-ins required about 380MB disk space. The MagicDraw web site recommends a Pentium™ 4 1.4GHz and 1GB RAM for NT/2000, and 2GB RAM for Windows Vista. Other operating systems supported included Linux and Mac OS X. We used Lenovo T61p Thinkpads with 3GB RAM for the evaluation.
Installation was relatively straightforward: install the core MagicDraw tool, then unzip the SysML and DoDAF plug-ins into the “MagicDraw UML”
directory (under Program Files). Unlock keys for the core MagicDraw product as well as the SysML and DoDAF plug-ins had to be placed on the hard drive (I put them in the “MagicDraw UML” directory. The e-mails automatically sent to the registered user upon downloading the plug-ins and containing the keys explained the process reasonably well. The software looked for these keys upon loading, and once pointed to the file locations never asked for them again.
One issue with the free demo download – it only allowed for 20 classes to be created, which were all used by the DoDAF plug-in upon startup to stereotype different classes as different diagram/object types in DoDAF. A call and an e-mail to No Magic solved the problem via updated unlock keys. We suspect that this may be “on purpose” to force engagement with the No Magic sales staff.
OVE R AL L AR C HITE C TUR E
MagicDraw is a thick client tool and the tool we reviewed creates a file for each project, within which it stores artifacts. With multi-user versions, we’d expect that it would allow for
creation of these project files in shared spaces, but that was untested. The multi-user version employs record-locking to allow for multiple users to simultaneously access different artifacts within the tool.
MagicDraw has an additional cost add-on called RConverter that will allow one to import IBM Rational Rose diagrams into MagicDraw directly.
It is important to note that the importing of comma separated variable artifacts is also a for- cost add-on; most tools include this at no cost.
Customizability
Magic Draw enables customization via what it calls “Domain Specific Language” – a model- driven approach based on UML profiling. This allows for the ability to adapt domain specific profiles to create custom diagrams, custom specification dialogs, custom real-time semantic rules, and other customizations saved in profiles within the project.
Capability and Use
From a “pointing and clicking” perspective, we were pleasantly surprised at the ease with which one can create and navigate between artifacts within the tool, and how quickly one could learn to use the tool. No tool is perfect, but this one is better than many that we’ve used. From a DoDAF perspective, it’s not particularly scalable, but we believe this to be a limitation of UML vs.
a limitation of this particular tool; this is elaborated upon below. A more detailed discussion of our user experience follows.
With our unfamiliarity with the tool, we downloaded and read the “DoDAF Plug-in User’s Manual” provided by No Magic at:
It’s actually very informative, and helps one understand how they have chosen to implement DoDAF in the UML/SysML notation using the tool. Also useful are No Magic’s online tutorials at:
Upon initially opening the tool, MagicDraw presents one with an initial navigation pane (“Welcome screen”), within which you can Manage Projects, see “Latest News” from No Magic and use the “What’s New” link to view release notes for the version loaded. There is also a “Resources and Plug-ins” link and a
“Samples” link. It’s a pretty clean opening page,
but those working on “one and only one” project can bypass it and get directly to work through settings under Options=>Environment.
When a user opens a new or saved project (including samples provided by No Magic), the tool presents itself in a fairly standard fashion:
there is a navigation pane on the left, an outline view tool under it (shows you “where you are” in the diagram and other details about the object selected in the browser, etc.), tool icons across the top, a editing/work area to the right, and a messages area below.
Something that’s not intuitively obvious, but nonetheless helpful: in the browser on the left, if the user navigates to the “Index” object under
“Data” and double-clicks it, one is presented with a Content diagram depicting two objects: a
“Structure” object, and a “General Workflow”
object.
Double clicking on the “General Workflow”
object presents one with “a means” (and a “not bad means” at that…) of working through the set of products within DoDAF. Using the “fit for purpose” mantra being socialized within the draft DoDAF 2.0 documents, one only creates products necessary for the purpose for which they’re creating the architecture, but this provides a good roadmap for product creation.
If you’re going to be making regular use of the tool, printing it, and pinning it to your wall isn’t a bad idea.
Double clicking on any of the elements within this diagram takes you to the metamodel view within MagicDraw of the product (in this case,
the OV-5 Operational Activity Model work product):
Returning to the Index Diagram, and double clicking the “Structure” object presents one with a hierarchical view of the DoDAF.
This is useful. Something even more useful is found by double-clicking one of the products.
One is presented with a description of the artifact from DoDAF and applicable diagram types within MagicDraw that can be applied to the product. These containers allow for one to drag-and-drop artifacts into them from the browser, and present the artifacts as a shortcut icon to the diagram. For those familiar with DoDAF, they may want to directly create the artifacts without using these road mapping tools;
however, even being intimately familiar with DoDAF, we found these useful.
Another useful feature: while creating the artifacts (in this case, an OV-5 Activity Diagram - Note that this is the MagicDraw term, due to the use of a particular UML diagram, as opposed to the work product name (Operational Activity Model) in the DoDAF specification. ), when one selects an object (in this case, and Operational Activity), icons appear to the right that are context-sensitive (i.e., the only objects that appear are ones that the object selected can connect to within the notation). This allows for quick creation of model artifacts.
Reporting within MagicDraw appears to be very robust, and all of the DoDAF matrix-based products (OV-3, SV-6) are created via report.
The only potential problem with the OV-3/SV-6 reports is they come out in RTF (vs. CSV or MS Excel format) with multiple columns’ information put into single columns; this could be problematic when trying to combine data created by MagicDraw with other tool vendors’ OV-3/SV- 6 solutions.
Quirks (all tools have them):
• The auto save function “takes over” the machine when it begins executing; not a good thing when one is presenting multiple artifacts to a customer in different formats (PowerPoint, etc.).
• One must be careful when creating diagrams that the correct container is highlighted; otherwise, it dumps the artifact under the top-most “Data”
container.
CONCLUSION
In the endgame, MagicDraw is relatively easy to learn, and appears to have implemented DoDAF in UML as called for in DoDAF 1.5. Specifics on the DoDAF implementation follow
Something that was relatively unique (and we thought appropriate…) is MagicDraw’s implementation of the OV-5; it implements the OV-5 hierarchy in a Class Diagram, and uses the UML Activity Diagram to implement Activity Flow at the leaf (i.e., lowest) levels in the Class Diagram. However, it wasn’t intuitively obvious how to make these associations in the tool beyond naming the artifacts the same thing (i.e., there was no way to drag-and-drop activities created in the node tree format [called
“Operational Activity Hierarchy” within Magic Draw] from the browser). Within the DoDAF Sample provided, they tried “really hard” to make the UML Activity Diagram look like an IDEF0 diagram; however, UML Activity diagrams are more akin to Business Process Modeling Notation (BPMN) or IDEF3 process flows.
These notations are designed to show process in the form of ordered activities, and (assuming swim lanes are added) who accomplishes the activities. The only major problem with this is depicting information exchange between the activities. However, we believe this to be more a problem with UML than MagicDraw’s DoDAF implementation using it – more below.
Information Exchanges: two of the major products in DoDAF, the OV-3 and SV-6, are primarily concerned with information/data passing between Organizations, People/Systems, and the Activities they’re accomplishing. There are a couple of potential problems here, MagicDraw has provided “a means” (not necessarily the best means, but “a means”) of working around it:
• OV-2 within MagicDraw is accomplished via using a Class Diagram, with Classes stereotyped as Operational Nodes, and Associations stereotyped as Needlines.
Adding Information Exchanges to the Needlines is a completely manual process, and does not use any information from MagicDraw’s OV-5 Activity Flow Diagrams or OV-6c Sequence Diagrams. The good news is that the OV-3 reports on information in the OV-2 diagram, but more automation here would have been a plus
• SV-6 is a report on the SV-1, which is created similarly to the above; System Data Exchanges are manually created within the diagram.
• However, these “problems” are endemic to the UML notation; we’re already hearing a collective gasp and anticipating hate mail from the UML zealots out there. That being said, before composing this retort, consider the following: UML is designed to help software architects conceptualize the problem space using the concepts of abstraction and polymorphism, and is not designed to report on information exchanges across boundaries (it’s good at what it’s designed to do… it’s just not good at looking at information exchange between Classes/Objects…). However, the Unified Profile for MoDAF and DoDAF (UPDM), which creates over 100 stereotypes to model MoDAF/DoDAF in UML/SysML, is an attempt by the community to alleviate these and other problems implementing MoDAF and DoDAF using UML
(see
for the UPDM
specification).
It may look like we’re hammering MagicDraw here – we’re not… most tools have warts, and that’s what we’ve documented. We’ve also documented several areas where No Magic has done an extremely good job of implementing a tool for creation of UML/SysML artifacts for DoDAF – overall they’ve done a good job - it’s a good tool.
Quick Scorecard: (0-4) 4 Overall Ease of Use
3 Coverage of EA Modeling Needs 4 Adherence to Model Standards 3 Automation of Model Build/Edit
4 Appearance and Readability of Models 4 Use of Model Data Internally
2 Use of Model Data Externally (interfaces) 3 Reports Included
3 Reporting Writing Capability 3 Stability
2 Use on a Large EA Program 3 Customizability
38 Total (out of 48)
0=no applicability; 1=Poor; 2=Fair; 3=Good; 4=Excellent
ABOUT NO MAGIC™
Victoria S. Girdziunas and Paul T. Ducanson founded No Magic in July of 1995 with the vision that there is no magic to develop better software. No Magic, Inc. is a Wyoming Corporation, with software development facilities are located in the EU (Kaunas, Lithuania) and Thailand (Bangkok). No Magic’s Corporate and Sales headquarters are located in Plano, Texas.
MagicDraw v1.0 was released in 1998, and its current release at the time this review was written is v16.0. The product has received several awards, including the Jolt Productivity Award (2007, 2005) and the Java Developer’s Journal Reader’s Choice Award (2006, 2003).
No Magic is a member of OMG (Object Management Group, a standards organization developing UML, CORBA, MDD and other standards), CodeGear and Sun Technical Partner.
Corporate Headquarters:
7304 Alma Drive, Suite 600 Plano, TX 75025
Phone: +1-214-291-9100 Fax: +1-214-291-9099 E-mail:
TOOL COST
For a single-seat, undiscounted license of MagicDraw Enterprise with SysML and DoDAF plug-ins (DoDAF plug-in requires installation of the SysML plug-in…), plus maintenance for a year, the cost is on the order of $4500. There will likely be discounts available for government, multi-user licenses, etc., but expect to pay on the order of $4-5k per seat.
The cost for the “Applying DoDAF with MagicDraw” course is $2000. However, before attending, we strongly recommend a tool-neutral course in DoDAF; these are offered by a number of organizations, including:
• W
• AFCEA
• FEAC Institute
AUTHOR BIOGRAPHIES
Lawrence McCaskill is Chief Enterprise Architect at WBB Consulting®, a technical and management consulting firm At WBB, he has overseen or created over 40 architectures supporting the Joint Capabilities Integration and Development System (JCIDS).
Of note are the E-2C/D, F-22A, MV/CV-22 Osprey, Joint Light Tactical Vehicle, and the MQ-1 Predator/MQ-9 Reaper, and several Net-Enabled Weapons architectures. In prior architecture-related positions, he developed architectures depicting net-centric operations and Global Information Grid (GIG) 2.0 Architecture. He was Chief Architect at Headquarters Air Force Special Operations Command and part of the initial cadre that developed the Activity Based Modeling methodology. Mr. McCaskill teaches the WBB tool-neutral DoD Architecture Framework course and currently participates in the DoDAF Working Group. He holds a Bachelor’s degree in Computer Engineering from the University of Miami, FL, and a holds a Master’s degree in Software Engineering from the University of West Florida. He has also authored/co-authored three papers for the International Command and Control Research and Technology Symposium.
Ian Komorowski is the Manager of Federal Architecture Requirements at WBB Consulting®, a technical management and consulting firm experience in developing architectures for commercial and government customers. Ian has also developed and taught a variety of classes on enterprise architecture among which include: tool neutral DoD Architecture Framework, Telelogic System Architect DoDAF ABM, and Department of Health and Human Services EA Modeling (based on a custom HHS framework implemented in Metis) classes. He can be reached at 703-448-6081 x265
or
An Information Model for Managed Application Landscape Evolution
By Sabine Buckl, Alexander M. Ernst, Florian Matthes, and Christian M. Schweda
Abstract
Planning, managing, and maintaining the evolution of the application landscape is a focal point of enterprise architecture (EA) management. Whereas, planning the evolution of business support provided by the business applications is understood as one challenge to be addressed in landscape management, another challenge arises in the context of traceability of management decisions. This article discusses the requirements regarding support for landscape management as risen by practitioners from industry, gathered in an extensive survey during which the tool support for EA management was analyzed.
Thereby, a lack of support for this management discipline was discovered, which is caused by the way, application landscapes are modeled in tools. We subsequently discuss how to incorporate these requirements into an information model.
Keywords
enterprise architecture management, management tools, modeling, temporality, historization, traceability
INTRODUCTION
Over the last years enterprise architecture (EA) management has become an important management area, many companies are currently executing or planning to introduce in the nearby future. As a consequence of the increased attention, a multitude of methods for EA management has been developed by academic communities (Buckl et al, 2008;
Lankhorst, 2005; Winter et al, 2007), standardization bodies (e.g., The Open Group, 2007), or practitioners (Dern, 2006; Keller 2007).
Although these methods differ substantially concerning the quantity, abstractness, and granularity of the EA documentation, which is needed for performing EA management, the need for a documentation of the body of management is common. As a consequence, different methods for creating such a documentation as well as for maintaining its timeliness have been subjected to research, commonly attributing this documentation as a model of the EA (Fischer et al, 2007).
The methods and models have to cope with a set of challenges arising in the context of EA
management, especially when the management of the application landscape as a central task is concerned. The term application landscape in this context refers to the entirety of the business applications and their relationships to other elements, e.g. business processes in a company. We abstain from using the term application portfolio, which we regard to have a narrower focus. During information gathering not only information about the as-is situation of the landscape has to be collected, but also information about future aspects, e.g. projects changing the application landscape, or business support provided by a newly introduced business application, has to be maintained. In order to get an overview on the relationships and dependencies of the various elements of the enterprise, different kind of visualizations, which we refer to as software maps, are typically used.
Figure 1 shows an exemplary software map, a so-called process support map, utilizing positioning of symbols to show, which business processes are supported by which business applications at which organizational units.
Thereby, chevrons representing a sequence of processes make up the x-axis. The y-axis is
Article
made up of labels representing organizational units. The rectangles symbolize business applications, and their positioning indicates
which business process is supported at which organizational unit.
Figure 1. Exemplary Process Support Map
Different versions of process support maps are commonly used to document the evolution of the application landscape, illustrating either the as-is or future business support at a certain point in time (planned for). In order to create these documentations, the respective data has to be stored in a repository corresponding to an information model, which defines the respective elements to be modeled.
Furthermore, landscape management is closely connected to project portfolio management, as the selected project portfolio determines the future development of the application landscape in the next planning cycle. Regarding the state of the art in the context of project portfolio management, most decisions about project portfolios are currently based on gut feel, not on information, which is derived from a comparison of different variants of the landscape regarding quantitative or qualitative aspects (cf. Lankes and Schwenda, 2008). The landscape variants thus indicate the outcome of different project portfolios and can therefore be used to provide
decision support, for example, in project portfolio management.
EA management and especially landscape management are understood to be endeavors following a typical management cycle consisting of the phases: Plan - Do - Check – Act (Deming, 1982; Shewart, 1986). Thereby, the traceability of management decisions taken in the Plan phase and implemented in the Do phase, must be ensured to control the achievement of objectives. In the context of a management cycle traceability of decisions can be achieved by storing previous states of the managed objects. The respective technique is sometimes referred to as historization An exemplary question in this context could be: Is the status of the planned landscape reached within the planned time frame or has the plan been changed? This information is subsequently used to prepare the next management cycle (Act).
Consequently, a third type of information has to be stored in an information model for landscape management besides the planned for and the
variant information as mentioned before: the moment in time the landscape was actually modeled (modeled at). From this discussion the following research question can be derived:
How should an information model for landscape management be designed to incorporate both business and technical aspects, and to support future planning and traceability of management decisions?
This question must especially take the aspects of temporality as connected to landscape management into account. Therein, different versions of the landscape are of importance: the current, planned, and target version. The current landscape represents the status quo of the landscape as is, modeled at a certain time. The planned landscape represents a future state of the landscape as to be at a specific time in the future. In some publications on landscape management (e.g., Keller, 2007; Engles, 2008), the terms as-is and to-be are used to indicate the respective landscape version. We abstain from re-using this terminology, as especially the term to-be is often used ambiguously for both planned and target landscapes.
This state is modeled by an architect at a certain time, emphasizing e.g. the changes performed by projects up to that specific future date. The
various projects and their impacts transforming the EA from current to a planned state, can be made explicit using roadmaps (Buckl et al, 2009). As a long term perspective the target landscape shows the architecture of the application landscape as envisioned at a certain time following the strategies and goals of the enterprise. There is no need to have projects defined transforming the current or planned landscape into the target one. Furthermore, the target landscape does not necessarily specify deployed business applications but refers to envisioned future support providers.
Summarizing, the traceability aspects of landscape management lead to three different time-related dimensions:
• firstly, a landscape is planned for a specific time,
• secondly, a landscape has been modeled at a certain time, and
• thirdly, different variants of a planned landscape may exist.
Figure 2 below illustrates the relationships between current, planned, and target landscape as well as the different dimensions relevant for landscape management.
Figure 2. Current, Planned, and Target Landscape
The aforementioned research question is addressed in this article as follows: the next section gives an overview on current approaches to landscape management as described by researchers and practitioners in this field. Further, requirements - especially time-related ones - for an information model for landscape management are introduced.
Thereby, a framework for the analysis of the support for landscape management is established. Alongside this framework an analysis of the current tool support for landscape management is performed in subsequent sections of this article and discusses ideas, which can be used to create an information model for landscape management fulfilling the aforementioned requirements. Therein, especially solutions originating from related modeling disciplines are taken into account to develop an information model suitable for documenting and planning application landscapes. The final section of this article hints at further areas of research in the context of EA management and in particular landscape management.
REQUIREMENTS FOR AND CURRENT APPROACHES TO LANDSCAPE MANAGEMENT
Due to the importance of managing the application landscape as a constituent of EA management, a number of different ways to approach this task have been proposed both in practice and academia. Subsequently, we give an overview on these approaches with an emphasis on the aspect of temporality.
In Braun and Winter (2005) the application landscape is referred to as a concept specifying the enterprise's business applications and their interdependencies. This information is rejected in the information model of via interfaces utilized to interconnect the applications and/or their inner components. References from these application level concepts (on the application layer as expressed by Braun and Winter (2005) to business level entities, e.g. the different types of business processes (on the organizational layer of the model) are present and can be used to explicate the way, how business support is provided. More sophisticated considerations are not directly supported, e.g. the question at which organizational unit which business process is supported, by which business application,
cannot be answered based on the information model. The aspect of temporality is also only partially addressed, while the models contain ways to store life cycle states of applications, it does neither support planning transitions between life cycle states nor does it take projects into account.
In van der Torre et al (2006) the business applications as well as their relationships to other constituents of the EA are considered an important information asset, which should be presented to managers in an appropriate way to provide decision support. As presentation form of choice, they introduce a type of visualizations, called landscape maps, in which the business applications are related to business functions and products. This relationship is referred to as a ternary one, which could also be established between applications and two other concepts, although such considerations are not detailed in the article. Temporal aspects are not part of the approach, while ways to use the landscape map visualizations for interacting and changing the data in the underlying models are explicitly stated. Additionally, the focal point of the work of van der Torre et al (2006) is on the application landscape, not on the EA as a whole, i.e.
projects are not considered in the approach.
A slightly different focus on managing the application landscape is taken in the work of Garg et al (2006). Therein, especially the aspect of the interfaces connecting the business applications is put under research. The number of interfaces associated to a business application is considered an important impact factor, e.g. when changes to the application landscape are considered. In this context, Garg et al (2006) put special emphasis on documenting and analyzing the current application landscape. This information is used as input to coordinate potential change processes affecting the landscape - especially concerning risks associated to these processes.
While Garg et al (2006) take a rather detailed look on the business applications and their interconnections, relationships to business related concepts of the EA are not presented in their paper. Whereas, the topic of the evolution of the application landscape is indicated, actual planning of future states or transformation projects is not in the focus of this article.
In the work of Jonkers et al (2005) a language for enterprise modeling is presented, in which
they target the three layers of business, application, and technology. The concepts introduced on the different layers can be used for modeling the current application landscape, especially for explicating the business support provided by applications (components) via offered interfaces. Further, the approach refines the description of the business support by adding the supplemental concepts of business- and application-services respectively. These concepts can be used to describe the existence of a support without having to specify, which actual application is responsible for the support.
Thereby, target landscape planning could be facilitated. Nevertheless, planned landscapes are not in the scope of the model, which also contains no concept for modeling projects or explicating project dependencies.
The approach of multi-perspective enterprise modeling (MEMO) as discussed for example in the work of Frank (2002) that explicitly accounts for the modeling of IT concepts, as business applications, in an organizational and business context, described as organizational units and roles as well as business processes and services. The respective modeling language concerned with IT aspects, the IT modeling language (ITML) (see Kirchner, 2008), introduces the respective concepts, as e.g. the information system. According to the reference process described as complementing the language, these concepts should not only be used for documentation, but also for landscape planning. Nevertheless, projects are not part of the model, which also does not explicitly account for issues of time-dependence.
Beside the academic community, as alluded to above, also practitioners address the field of landscape management. In the work of Engles et al (2008) the application landscape is presented as a management subject embedded in the context of business and technical concepts, ranging from business processes to technical platform modules. The current landscape should, accordingly, be documented with references to these aspects, especially the technical ones. Complementing the current landscape, a so called ideal landscape (Target landscape in the terms used throughout this article) should be defined as part of a landscape management endeavor, incorporating technical visions of the landscape. Mediating between current and ideal, different to-be landscapes (in this article these landscapes are called planned ones)
should be developed, each of these landscapes is assigned to a set of projects, which must be executed to actually realize the respective to-be landscape. Here, a strong relationship between the projects and the to-be landscapes should be maintained in an underlying model, nevertheless means for tracing back the evolution of a to-be landscape are not incorporated.
Another approach originating from practical experience is given in Kirchner (2008), which also emphasizes on the importance of a managed evolution of the application landscape in the context of EA management. Thereby, a map similar to the process support map is used, focusing on the support provided by business applications for products instead of organizational units. Following the product- centered approach, different states, current and planned, of the application landscape are modeled in order to support the planning process. Thereby, projects are linked to the constituents of the EA in order to support the deduction of planning variants, called planning scenarios. In order to support the evaluation of these variants, (Neimann, 2006) discusses the usage of historization to support traceability of management decisions. Although, the documentation aspect of EA management is addressed, no integrated information model supporting the future planning of the application landscape is presented.
Subsuming the state-of-the-art in managing application landscapes as presented in literature, many common aspects can be seen, although different approaches are employed especially concerning the aspect of temporality.
Nevertheless, creating an information model of the application landscape is a widely accepted prerequisite employed in landscape management. In some of the papers, presented above, information models are provided, which introduce the concepts necessary for performing landscape management. These information models differ widely regarding the concepts and relationships introduced as well as regarding their complexity, because, among others, no common terminology for the concepts employed has yet been established. We regard, notwithstanding, such a model to be mandatory to approach landscape management as a whole and the important aspect of temporality in special.
Due to great interest from industry partners in information about EA management tools and especially their capabilities to address the concerns arising in the context of landscape management, an extensive survey - the Enterprise Architecture Management Tool Survey 2008 - was conducted (Matthes et al, 2008).
The survey pursued a threefold evaluation approach, relying on two distinct sets of scenarios together with an online questionnaire.
The survey was developed in cooperation with 30 industry partners (among others Allianz Group IT; Siemens IT Solutions and Services;
Munich Re; O2 Germany; BMW Group; and Nokia Siemens Networks). Thereby, the first set of scenarios focuses on specific functionality, an EA management tool should provide, without connecting these functionalities to the execution of a typical EA management task, e.g. 1) flexibility of the information model, 2) creating visualizations, or 3) impact analysis and reporting. The EA management tools were further evaluated by the scenarios of the second set, which reflect tasks that have been identified as essential constituents of many EA management endeavors, for example: 1) business object management, 2) IT architecture management, or 3) SOA transformation management. One of the most prominent scenarios of the second part is the scenario landscape management, which is concerned with the managed evolution of the application landscape (Aier and Schönherr, 2007). The concern of the scenario was described by the industry partners as follows:
Information about the application landscape should be stored in a tool. Starting with the information about the current landscape potential development variants should be modeled. The information about the current application landscape and future states should be historicized to enable comparisons. (Matthes et al, 2008)
Subsequently, a catalog of typical questions in the context of landscape management as raised by the industry partners is given:
• What does the current application landscape look like today? Which business applications currently support which business process at which organizational unit?
• How is, according to the current plan, the application landscape going to look like in January 2010? Which future support providers support which business process at which organizational unit?
• What was, according to the plan of 01-01- 2008, the application landscape going to look like in January 2010?
• How does the target application landscape look like?
• What are the differences between the current landscape and the planned landscape, according to the current plan?
What are the differences' reasons?
• What are the differences between the planned landscape according to the plan of 01-01-2008 and the current plan?
• What projects have to be initiated in order to change from the planned landscape (according to the current plan) to the target landscape? What planning scenarios can be envisioned and how do they look like?
Based on the questions from the industry partners and the different dimensions relevant for landscape management, the following requirements regarding an information model can be derived. An information model suitable for landscape management must:
• (R1) contain a ternary relationship in order to support analyses regarding current and future business support (which business processes are supported by which business applications at which organizational units),
• (R2) provide the possibility to specify envisioned business support in order to facilitate target landscape planning without having to specify implementation details of the business support,
• (R3) support the deduction of future landscapes from the project tasks, which execute the transition from the current to the future business support,
• (R4) ensure the traceability of management decisions by storing historic information of past planning states, which may be interesting especially if complemented with information on the rationale for the decisions, and
• (R5) foster the creation of landscape variants based on distinct project portfolios
in order to tightly integrate project portfolio management activities.
• From these requirements, we subsequently evaluate the support for landscape management as provided in the approaches from literature (see Table 1). A detailed discussion of the landscape management support provided by tool 1, tool 2, and tool 3 is given in the following section of this article.
Thereby, the support provided by the different approaches is indicated by different symbols
ranging from complete fulfillment of the requirement ( ) via partial fulfillment ( ) to approaches, which completely lack support for the analyzed requirement ( ). In addition, an overview on the support provided by exemplary tools, which were analyzed during an extensive survey (Matthes et al, 2008), is shown in Table 1. A detailed discussion of the used information models shipped with the respective tools is given in the following section.
Table 1. Existing Approaches and Tools and their Fulfillment of the Requirements
TOOL SUPPORT FOR LANDSCAPE MANAGEMENT
The solutions of nine major players in the market of EA management tools were analyzed regarding the information models, which they come shipped within (Matthes et al, 2008).
Three different exemplary models as employed by the different tools are subsequently explicated to provide an overview about the current operationalizations of landscape management. The attributes are thereby not shown to improve readability but are mentioned in the description, if necessary for understanding. Due to reasons of confidentiality the names of the tools analyzed are omitted.
Prior to discussing the different approaches taken by the tools, the core concepts relevant in application landscape management, are introduced and defined in an informal way. The definitions are taken from the glossary as presented in Buckl et al (2008), although minor adaptation have been applied to suite the specific stetting of the article:
• Business application. A business application refers to an actual deployment of a software system in a certain version at a
distinct location and hardware. Thus, business applications maintain versioning information in addition to the relationships to the business processes, they support at specific organizational units. In landscape management, the business applications are limited to those software systems, which support at least one business process.
Further, the business applications are the objects, which are transformed by the projects considered in application landscape management.
• Business process. A business process is defined as a sequence of logical, individual functions with connections in between. A process here should not be identified with a single process step, as found e.g. in an event driven process chain (EPC). It should be considered a coarse grained process at a level similar to the one used in value chains, i.e. partially ordered, linear sequences of processes. Additionally, a process maintains relationships to the business applications, which support him at the different organizational units. As in application landscape management, the business processes are considered to be fixed, i.e.
they are not transformed by projects.
• Business support provider. A business support provider is a constituent of an application landscape, used to indicate that a related business process is supported at a distinct organizational unit, without giving a specification, which business application is likely to provide this support, if any. In spite of the similarities to the business application, the envisioned support provider is not affected by projects but has nevertheless a period of validity associated. Thereby, it references the point in time it has been modeled at and (optional) the point in time, the provider became invalid.
• Organizational unit. An organizational unit represents a subdivision of the organization according to its internal structure. An organizational unit is a node of a hierarchical organization structure, e.g. a department or a branch. In application landscape management, organizational units are considered fixed - thus, they are not transformed by projects.
• Project. Projects are drivers of organizational change. Therefore, adaptations of the application landscape are the result of a project being completed.
Projects are scheduled activities and thus hold different types of temporal attributes,
their startDate and endDate on the one hand. On the other hand, projects are plannedAt respectively removedAt certain points in time referring to the time of their creation or deletion. This effectively results in a period of validity, which is assigned to each project. In application landscape management, projects are considered to only affect business applications in general and their business support provided, in special. Projects do not affect business processes or organizational units in this model.
Starting with a basic approach to landscape management Tool 1 presents an information model containing landscape management related concepts, as shown in Figure 3. Here, the business process is connected with the organizational unit via a business support provider, which can be used to support target landscape planning (cf. R2). Whereas data gathered according to this information model can be used to generally analyze the business support for a business process, the relationship to the organizational unit, where the support takes place, is not derivable unambiguously (cf.
R1).
Figure 3. Information Model of Tool 1
Figure 4 shows exemplary data instantiating the information model from Figure 3. Analyzing this data, a statement, which business process is supported by the Inventory Control System at the Subsidiary Munich cannot be made.
Besides the missing ternary relationship between business process, organizational unit, and support provider, the only concept carrying temporal information - the project - is connected to the support provider via the relationship affects. Due to the missing ternary relationship
no time information for the business support provided can be stored (cf. R3). In addition, planning variants of the landscape can only be built based on the business support providers instead of the business support provided (cf.
R5). Consequently, Tool 1 only rudimentarily supports the management of current, planned, and target landscapes. While such information might be sufficient for future planning in a one dimensional manner, the requirements as risen by the industry partners concerning traceability and versioning cannot be addressed (cf. R4).
Figure 4. Instance Data Corresponding to Information Model of Tool 1
Business Support
Business Support represents the support of a specific business process by a specific business support provider at a specific organizational unit.
The information model of Tool 2 (see Figure 5) incorporates the ternary relationship between the business processes, the organizational units, and the business support providers by introducing a dedicated class and respective associations (cf. R1). The association supportBy is further assigned life cycle parameters using a mechanism similar to an association class in UML. Thus, it is possible to indicate that the business support provided by a specific instance of class BusinessSupportProvider is at a certain point in time in a specific life cycle phase, e.g.
planned or active (cf. R2). This notion of life cycle is nevertheless disconnected from the concept of the project, which is independently associated to the class realizing the ternary relationship. While this association allows to
model, that the support for a specific business process executed at a specific organizational unit is affected by a project, no mechanism to indicate, which BusinessSupportProvider actually is changed by the project, is present (cf.
R3 and R5). This fact is caused by the * multiplicity on the BusinessSupportProvider end of the supportBy association. Therefore, an unambiguous mapping from projects to affected support providers is not possible. Further, the model does not support the creation of different landscape scenarios, as it is not possible to make projects or providers of business support belong together in one scenario. A mechanism for marking a BusinessSupportProvider an element of a target landscape is nevertheless provided via a flag attribute target in the association class supportBy. Historization of planned application landscapes is not supported (cf. R4) as no means for versioning instances corresponding to the model are given.
Figure 5. Information Model of Tool 2 Finally, the information model of Tool 3 (cf.
Figure 6), which is only slightly different from the model of Tool 2, provides additional support for
application landscape management - future state considerations are supported similarly as in Tool 2 (cf. R2). The information model
contains the business support concept (cf. R1) and also implements temporality in a one dimensional manner by the project concept (cf.
R3 and R5), which affects the business support and contains temporal information, e.g. start and end dates. Such information might be sufficient for planning the evolution of the EA, but is
somewhat limited concerning traceability of changes to the plans (cf. R4), which would demand support for bitemporal modeling. As an example, one might think of a plan for the EA regarding the year 2010, which might look different as-of begin 2008 respectively begin 2009.
Figure 6. Information Model of Tool 3
Refer to Table 1 for an overview about the evaluation results of the current tool support regarding landscape management in general and temporality aspects in special.
DEVELOPING A TEMPORAL INFORMATION MODEL
This section presents an information model meeting the requirements as introduced above and thus also addressing the research question as stated previously. To give a convenient and well understandable presentation of the model, the section starts with introducing the idea of temporal modeling. This introduction accounts for methods and techniques supporting the creation of time-related models - it has thereby a special emphasis on temporal patterns, i.e. on patterns for things that change over time (Carlson et al, 1999). Prior, temporal databases are briefly alluded to, as an early means for explicating time dependency of data. Finally, the core facets of an information model capable to address the aforementioned requirements are explicated.
Introduction to Temporal Modeling
The question of how to incorporate temporal dependencies into a model has been repeatedly discussed in computer science. A very prominent approach to this question originates from the field of database research, where
temporal databases were designed as means for bitemporal modeling, i.e. modeling of entities that change over time but have to maintain previous states accessible. Subsequently, we sketch the core principle of bitemporal modeling.
For a more comprehensive treatment of the field in the context of databases (see for example the work of Date, 2000). In the simplest case, a timestamp would be added as a further column to a table, which should be enriched with temporal information. Thereby, it becomes possible to determine, since which point in time the respective row is valid. This simple solution has the drawback that it is not directly possible to specify, that a table row is valid for a certain period of time. Nevertheless this drawback can be resolved by adding another column for storing the end of the period of validity. If traceability of changes should further be considered, an additional temporal attribute has to be specified in addition to the period of validity. According to Date (2000), this can be achieved by introducing two more temporal attributes defining a respective time interval and thus capturing the sequence of states of a changing table. Such a table is than called a bitemporal table.
In the area of object-oriented modeling, similar discussions on how to incorporate time- dependencies have been undertaken. From these discussions, a set of temporal (design) patterns (e.g., Arnoldi et al, 2008) has emerged.
The publication by Anderson (1999) gives a good overview. Prior to this overview, the article introduces basic time-related concepts as commonly encountered in temporal object- oriented models:
• Event. An event triggers a change of state in a system, i.e. a model. An event has a timestamp associated, responsible to record the time of the occurrence. According to [2], events may not always be (natural) first class objects in the respective modeling domain.
• Time Interval. A time interval has a specific start and end event, which allows the derivation of a duration of an interval.
These basic concepts are utilized by the temporal patterns, which address specific time- related design issues
One widely used pattern is the temporal property as discussed in Carlson et al (1999) and Fowler (2008). This pattern is also known as “‘historical mapping” or “time-value pairs.” If the need to track how this property has changed (or is expected to change) exists, the temporal property pattern can be used. The pattern therefore assigns a period of validity to the respective property value, to reflect that the value is only valid for a discrete interval of time.
For achieving this, the property, if not a priori modeled in a first class concept, is converted to a value class. This class not only contains the respective property value but is further augmented with two more properties indicating the start- respectively end-time of the validity period. Nevertheless, using this pattern to address issues of time-dependency for properties does not come without costs - the introduction of an additional class adds further complexity to the respective model, while lowering modeling clarity. The later becomes obvious, when considering multiplicities in the model. A property owner may have exactly one value for a property assigned at a specific point in time. However, there may be multiple instances of the respective value class assigned to the same owner, as they represent the history of property values over time. To address this loss of modeling clarity and make the model structure more concise, the utilization of a UML stereotype (the Object Management Group, 2005) <<temporal>> is recommended. Figures 7 and 8 exemplify the issue as raised above, by
modeling the last name of a person as temporal property without and with the stereotype respectively.
Figure 3. Temporal Property Model without Stereotype
Figure 8. Temporal Property Model with Stereotype
In order to fulfill the requirements as mentioned previously, especially R4 and R5, the pattern temporal association (see Carlson et al, 1999) can be used on the business support concept, as this concept actually explicates a (ternary) association. This pattern introduces additional attributes similar to the temporal property to supply a period of validity for the business support.
If landscape plans for the same point in time created at different times should be compared to each other (cf. R5), the information concerning the point, when the project has been planned at, had to be considered. Consistently, the temporal pattern edition (Carlson et al, 1999) could be used to implement this mechanism.
An Information Model for Landscape Management
The information models from Tools 2 and 3 as presented in Section 3 both form good starting points for a compulsory information model for landscape management fully satisfactory also in respect to the time-related requirements.
Nevertheless, the incorporation of the project concept in both models is not completely satisfying in two ways:
• The affects relationship does not distinguish clearly between the different types of influence a project can have, namely introduction, migration, and retirement.
• Projects do not only change the business support, but also influences business applications. In fact, projects (IT projects) mostly perform changes on the business application leading to a change in the business support provided thereby.
The first limitation, mentioned above, can be resolved easily, e.g. by introducing two relationships effectively replacing the affects relationship. These relationships can be labeled introduces and retires respectively, a migration is thus indicating by using both relationships. In contrast, the second limitation is not that easy to release; projects or parts thereof (project tasks) must consequently be associated to any affectable concept. This can actually be achieved in many different ways, e.g. via distinct project (task) types that affect only business applications or business supports. A maximum of genericity can be reached by introducing a basic concept for any concept, which can be affected by a project or a part thereof and to use respective inheritance in the information model.
We further pursue this approach and introduce the respective basic concept and its associations to project tasks, which are used to model distinct activities within a project. The model incorporating this idea is shown in Figure 9. In this information model, any project affectable can derive its period of validity from the start and end dates of the transitively associated projects. Thereby, inheriting from project affectable makes it possible to assign a project dependency to a concept in the information model. Nevertheless, using the standard UML-notation for inheritance would make the model less easy to perceive, as many classes are likely to inherit from project affectable. To make the resulting model more concise, we introduce an additional stereotype
<<projectDependency>>, which can be assigned to a class in order to indicate, that this
class is actually a subclass of project affectable (cf. Figure 10).
Figure 9. Project Affectable and Project with Exemplary Child Class
Figure 10. Exemplary Child Class with Stereotype
The information model presented in Figure 9 is complemented with an OCL constraint:
context ProjectTask
inv: introduces.type==retires.type
With this abbreviating notation at hand, an information model for landscape management satisfying the requirements (R1)-(R4) and
explicating the stereotype
<<projectDependency>> can be provided in Figure 11 on the next page.
