Abstract
A business capability map is used as a starting point for deriving an application landscape. Software applications are the counterpart to business capabilities as they implement desired functionality. In the same way, business objects reflect a high-level picture on data objects maintained by business software. Applications and data objects describe corporate information systems.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
Customer, order and invoice have already been introduced before. Revenue represents the income of a company.
- 2.
We should not forget the vessel in Fig. 1.6 on page 11. Having no strict Governance on IT can result in a plethora of (redundant) systems and, therefore, increase IT budgets.
- 3.
Corporate application landscapes can have a couple of hundred or more than thousand software applications.
- 4.
Each application is potentially connected to several others, resulting in thousand of interfaces.
- 5.
Needless to say, that such a map is rather the exception as real architectures are much larger and contain a lot of issues.
- 6.
The decisions should be made on business objects. We refer to data as business objects as it represents business data on a high level. We will further elaborate on this in Sect. 3.4.
- 7.
Imagine having a capability map with ten top-level capabilities that are decomposed by two more levels. If each (sub-)capability is in average decomposed into 5 sub-capabilities the we will have around 310 capabilities (10 on level one, 50 on level two and 250 on level three).
- 8.
We will transfer this principle to data objects as well. In the remainder of this section, data flow and exchange of business objects will be used synonymously.
- 9.
- 10.
Example activities are: export processing finalised, customs clearance done, shipment sent to destination country, shipment on hold.
- 11.
Transforming the application landscape will be further discussed in Sect. 5.1.
- 12.
Applications—as any resource—do not have a business relevance. Their relevance is decided by the business they are supporting as only value-add provides result in a corporate environment.
References
T. Erl, Service-Oriented Architecture, Concepts, Technology, and Design (Prentice Hall, 2005)
M. Amundsen, M. Mclarty, Microservice Architecture, Aligning Principles, Practices, and Culture (O’Reilly, 2016)
M. Lankhorst, et al., Enterprise Architecture at Work: Modelling, Communication and Analysis, 3rd edn.. The Enterprise Engineering Series (Springer, Berlin, Heidelberg, New York, NY, 2013)
G. Wierda, Mastering ArchiMate: A Serious Introduction to the ArchiMate Enterprise Architecture Modeling Language, Version 3.0.1, Edition III. TC1 (R&A, The Netherlands, 2017)
S. Tilkov, Why You Should Avoid a Canonical Data Model (2015). [Online]. Available: https://www.innoq.com/en/blog/thoughts-on-a-canonical-data-model (visited on 03/12/2021)
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2021 The Author(s), under exclusive license to Springer Nature Switzerland AG
About this chapter
Cite this chapter
Jung, J., Fraunholz, B. (2021). Developing Application Architecture. In: Masterclass Enterprise Architecture Management. Springer, Cham. https://doi.org/10.1007/978-3-030-78495-9_3
Download citation
DOI: https://doi.org/10.1007/978-3-030-78495-9_3
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-030-78494-2
Online ISBN: 978-3-030-78495-9
eBook Packages: Computer ScienceComputer Science (R0)