Architecture Alignment

  • Marc Lankhorst
Part of the The Enterprise Engineering Series book series (TEES)


As we have described in Chap. 1, achieving alignment between business and IT is one of the most important drivers for architecture. Architecture alignment is the problem of designing architectures at the infrastructure, application, and business levels such that each fits optimally with the other architectures. By studying project documentation obtained in case studies in several large Dutch organisations, we have tried to find alignment patterns that are actually used in practice. These results provide the context in which architectures are designed. Insight into this context helps the reader in better applying the techniques presented in this book.


Business Process Business Unit Business System Business Process Model Software Infrastructure 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.


  1. Blanchard BS, Fabrycky WJ (1990), Systems Engineering and Analysis. Prentice Hall, Englewood Cliffs, New Jersey.Google Scholar
  2. Buschmann F, Meunier R, Rohnert H, Sommerlad P, Stal M (1996), A System of Patterns: Pattern-Oriented Software Architecture. Wiley, New York.Google Scholar
  3. Conway ME (1968), How do committees invent? Datamation, 14(4):28–31.Google Scholar
  4. Dijkstra EW (1968), Structure of the ‘THE’-Multiprogramming System, Communications of the ACM, 11(5):341–346.CrossRefGoogle Scholar
  5. Eertink H, Janssen W, Oude Luttighuis P, Teeuw W, Vissers C (1999), A Business Process Design Language, Proc. 1st World Congress on Formal Methods, Toulouse, France.Google Scholar
  6. Hall AD (1962), A Methodology for Systems Engineering. Van Nostrand, Princeton, New Jersey.Google Scholar
  7. Hall AD (1969), Three-Dimensional Morphology of Systems Engineering. IEEE Transactions on System Science and Cybernetics, SSC-5(2):156–160.CrossRefGoogle Scholar
  8. Hardjono TW, Bakker RJM (2001), Management van processen: Identificeren, besturen, beheersen en vernieuwen. Kluwer, Dordrecht (in Dutch).Google Scholar
  9. Harel D, Pnueli A (1985), On the development of reactive systems. In Apt K, (Ed.), Logics and Models of Concurrent Systems, pp. 477–498. NATO ASI Series. Springer, Berlin.CrossRefGoogle Scholar
  10. Henderson JC, Venkatraman N (1993), Strategic alignment: leveraging information technology for transforming operations, IBM Systems Journal, 32(1):4–16.CrossRefGoogle Scholar
  11. Kruchten P (1995), Architectural Blueprints – The ‘4+1’ View Model of Software Architecture, IEEE Software, 12(6):42–50.CrossRefGoogle Scholar
  12. Martin, J (1982), Strategic Data-Planning Methodologies. Prentice Hall, Englewood Cliffs, New Jersey.Google Scholar
  13. Martin, J (1989), Information Engineering (3 vols.). Prentice Hall, Englewood Cliffs, New Jersey.Google Scholar
  14. Olle TW, Hagelstein J, Macdonald IG, Rolland C, Sol HG, van Assche FJM Verrijn-Stuart AA (1988), Information Systems Methodologies: A Framework for Understanding. Addison-Wesley, Reading, Massachusetts.Google Scholar
  15. Pahl G, Beitz W (1986), Konstruktionslehre. Handbuch für Studium und Praxis. Springer, Berlin.Google Scholar
  16. Roozenburg NFM, Eekels J (1995), Product Design: Fundamentals and Methods. Wiley, New York.Google Scholar
  17. Smith JM, Smith DCP (1977), Database Abstractions: Aggregation and Generalization, ACM Transactions on Database Systems, 2:105–133.CrossRefGoogle Scholar
  18. Sowa JF, Zachman JA (1992), Extending and Formalizing the Framework for Information Systems Architecture, IBM Systems Journal, 31(3):590–616.CrossRefGoogle Scholar
  19. Treacy M, Wiersema, F (1997), The discipline of market leaders. Perseus Publishing, Reading, Massachusetts.Google Scholar
  20. Van der Sanden WAM, Sturm BJAM (1997), Informatiearchitectuur, de infrastructurele benadering. Panfox, Rosmalen (in Dutch).Google Scholar
  21. Van Eck PAT, Blanken H, Wieringa RJ (2004), Project GRAAL: Towards operational architecture guidelines. International Journal of Cooperative Information Systems, 13(3):235–255.CrossRefGoogle Scholar
  22. Van Velzen RCG, Van Oosten JNA, Snijders T, Hardjono TW (2002), Procesmanagement en de SqEME-benadering. Kluwer, Dordrecht.Google Scholar
  23. Weill P, Vitale M (2002), What IT Infrastructure Capabilities Are Needed to Implement E-Business Models? MIS Quarterly Executive, 1(1):17–34.Google Scholar
  24. Wieringa RJ (1996), Requirements Engineering: Frameworks for Understanding. Wiley, New York.Google Scholar
  25. Wieringa RJ (1998a), Postmodern Software Design with NYAM: Not Yet Another Method. In Broy M, Rumpe B (eds.), Requirements Targeting Software and Systems Engineering, LNCS 1526, pp. 69–94. Springer, Berlin.CrossRefGoogle Scholar
  26. Wieringa RJ (1998b), A Survey of Structured and Object-Oriented Software Specification Methods and Techniques, ACM Computing Surveys, 30(4):459–527.CrossRefGoogle Scholar
  27. Wieringa RJ (2003), Design Methods for Reactive Systems: Yourdon, Statemate and the UML. Morgan Kaufmann, San Francisco.Google Scholar
  28. Wieringa RJ, Blanken HM, Fokkinga MM, Grefen PWPJ (2003), Aligning application architecture to the business context. Proc. Conference on Advanced Information System Engineering (CaiSE’03), LNCS 2681, pp. 209–225. Springer, Berlin.Google Scholar
  29. Zachman JA (1987), A Framework for Information Systems Architecture, IBM Systems Journal, 26(3):276–292.CrossRefGoogle Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2013

Authors and Affiliations

  • Marc Lankhorst
    • 1
  1. 1.NovayEnschedeThe Netherlands

Personalised recommendations