Skip to content

Latest commit

 

History

History
55 lines (33 loc) · 6.12 KB

introduction.md

File metadata and controls

55 lines (33 loc) · 6.12 KB
Raw

Introduction

Smart people have been thinking on how to create IT architectures as long as there has been computers. Ideas come and go, however creating a good architectures can still be complex and time consuming. Especially when you try to invent the wheel for yourself. With this interactive playbook you can create your IT architecture better and faster. The focus of this architecture playbook is in on:

  1. Knowledge reuse. Why reinvent the wheel again? It is far and more fun to create a better wheel for your organisation or IT project instead! Focus on the hard complex context specific issues. Use good open tools and knowledge for the easy 80%!
  2. Easier creation of architecture documents and deliverables. This playbook has an extensive list of all(*) open tools available for creating your IT architecture or design. Using these open tools will speed up the process of creating your architecture deliverables and reduce your risks.
  3. Quality improvement. By making use of content parts provided for various architecture deliverables you will lower your business risks. Complex business IT projects will fail. Now and in future. But if you make use of proven methods and tools developed from decades of IT architecture scientific research you will lower the risk for your project. Architecture will help to make your projects more successful in terms of costs, speed and profitability.

(*) If you miss a good open tool that is also usable for IT architecture creation, do not hesitate to contribute to this open publication!

This architecture playbook is divided in the commonly used architecture sections:

  • Business
  • Data
  • Applications and of course
  • Technology Infrastructure (TI)

This playbook is primarily created for on-line usage. But also ePUB and PDF versions are available.

Why this architecture playbook?

Creating a business IT architecture has many benefits. However creating a complete architecture is known to be:

  • Difficult
  • Time consuming

Of course many tools have been developed the last 30 years to make creating architecture (documents) easier. However many tools force you into a very tight harness without the needed flexibility. Complex problems need flexible solutions and tools should not slow you down in creating sketches, documents and typical architecture deliverables. A one size fits tool for solving complex business IT problems does not exist. And since creating good architectures is knowledge intensive work that delivers real value for business you should be aware of vendor lock-ins and using methods and tools that do not share knowledge sharing. Open Source tools and open access documentation offer a default head start for reuse and improvement of knowledge work in IT architecture.

You can buy and read many many books on how to do architecture well. All books claim a magic method and promise ultimate success when followed. We love books and reading methods. E.g. TOGAF. However this playbook is different. This architecture playbook is not about describing how you should create your architecture. You are free to use every method you want. This architecture playbook is all about giving you direct usable content and tools that you can use and reuse for your architecture challenge.

So this playbook brings you ultimate freedom and flexibility. You can export the results from certain tools in any desired format. In this way you can still use your architecture enterprise tool(s) that you already have invested deeply in. So use the outcome of tools within this playbook in combination with the enterprise architecture tool that are mandatory within your organisation.

What is in this architecture playbook?

Many good books and courses already exist that cover the why and how of (Enterprise) IT architecture. So this book will not explain aspects and concepts of the very broad field of IT architecture. This playbook is targeted on providing practical tools for creating your IT architecture or design faster and better. So the focus is 100% on the real thing by using the following leading principles:

  1. Tools that speed up creating your business IT Architecture.
  2. Collections of principles, requirements, standards and reference architecture that speed up the creation of your architecture deliverable.
  3. Collection of various Architecture OSS Tools that speed up creating your business IT architecture.
  4. Collection of architecture QA tools to control and manage your IT projects.
  5. Collection of reusable reference architectures, foundation architecture, architecture journals and more. Knowing where you can find what in an easy way will reduce your time. So you will have more time to spend on solving your problem in your organization.

Caution: This architecture playbook contains OPEN material only!

This architecture playbook is created to be open. This means that:

  1. This architecture playbook is licensed using a liberal license (CC-BY-SA). This means that you can reuse remix, transform, and build upon the material in this architecture playbook for any purpose.
  2. All tools mentioned within this architecture playbook are licensed under a OSS license and all documents referenced to is licensed under an CC license whenever possible.

This gives you the opportunity to reuse and mix content from this architecture playbook the way you want. This also means that all tools mentioned to in this architecture playbook are open and free to use without costs. We believe that sharing tools and knowledge, especially knowledge for making better architectures SHOULD be free. If you want to host this Architecture Playbook on your own company site, Intranet or just want to have more information on the OSS tools: Contact Us, or visit the github repository.

Notational Conventions

This architecture playbook uses the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”. This key words are to be interpreted as described in RFC 2119. Using these key words gives clarity and avoids confusion.