Business Architecture

A Business Architecture defines the structure of your organization in terms of its governance structure, business processes, business services and products, business information and stakeholders. A business architecture outlines the relation to strategic goals towards a working system. So in short a business architecture can be regarded as a blueprint of the working of an organization. By using a business architecture your organisation can handle changes and problems with less cost and in less time since you know all the important dependencies, relation and information flows.  Every successful organisation, small or large, SHOULD have a business architecture. A business architecture does not have to be fully descriptive, complete or created among a certain standard. Designing organisations and describing the working of an organisation is know to be complex and hard. However simple tools exist to create a meaningful business architecture for your organisation.

This section is created to speed up the process for creating a real business architecture.

You can use one of the following tools:

  • Business architecture template(s)

  • (Re)use  business principles

  • Modeling your business processes

  • Defining your business products

Tools for creating a business architecture

To speed up the process of creating your business architecture you can make use of one of the following tools:

  • Collection of many nice design principles used by companies (180+ examples).

  • Archi.  Archi™ GUI tool for creating a business architecture using the ArchiMate modelling™ language. The Archi tool is targeted toward all levels of Architects. The tool is MIT Licensed, so it provides a low cost solution to users who are looking for a free, open ArchiMate modeling tool.

  • Causal Loop Diagram. Tool to make easy causal loop diagrams in your browser. A causal loop diagram (CLD) is a causal diagram that aids in visualizing how different variables in a system are interrelated. This FOSS tool has an nice animation to presents effects also! The original (OSS) source can be found here. But the version on NOComplexity.com is a (GPL) fork with some extra features ( source code ).

  • Camunda Modeler. Camunda Modeler is an OSS desktop application for editing BPMN process diagrams(2.0) and DMN decision tables. Business Process Model and Notation (BPMN) is the global standard for process modeling and one of the most important components of successful Business-IT-Alignment. BPMN is an open standard. But there are not many good OSS available packages available. Camunda Modeler is an OSS BPMN solution and is part of an open source platform for workflow and business process management. So when you use the Camunda Suite you can also use the execution engine for your processes you have modeled.

  • Protégé. Protégé is an OSS web or desktop application that can be used for building business ontologies.

  • DrawIO. A online FOSS program to create diagrams. Its a very advanced, but also very simple to use program to create all types of (business) diagrams. UML, BPMN, ArchiMate, swimlane diagrams and many more. If you like to create good diagrams fast, think of using this program. Since its FOSS the source can be found on https://github.com/jgraph/drawio if you want to host it yourself. There is also a desktop version (electron build) of draw.io. Check https://github.com/jgraph/drawio-desktop.

Business Principles

Having solid business principles is key for a successful company. Small or large. Having good and solid business principles is key for developing a good architecture within solid time and cost constraints. Business principles SHOULD be defined and agreed upon within a solid process with all key business stakeholders involved. The list below with principles below can give you a head start, since these principles are collected from various successful businesses.

Solution space


Statement
Never try to use technical solutions to a non-technical problem.
Rationale
Of course some IT and technology can help to solve problems, but technology and IT is never enough. A non technical activity, process, behaviour change, etc is always needed.
Implications
Do not focus on technology and IT solution only when solving problems.

Start simple


Statement
Start simple.
Rationale
Start simple. Build a high quality solution to a real problem for a cohesive group of people. If you solve one problem really well, then you can move on to the next problem (one simple approach at a time) instead of trying to tackle several things at once and, as a result, not really solving anything. Product development is about earning the right to build the next thing.
Implications
Complexity will come later when having invest lots of time and money and simple adjustments have more impact. Fixes will be more complex when products are mature anyway due to backward compatibility requirements.

Create a MVP fast


Statement
If your MVP takes a year to build…it’s not an MVP.
Rationale
Creating a MVP should take not more than 1 month.
Implications
A created MVP is not ready for sale, but ready to learn from for later stages.

First, make it easy. Then make it fast.


Statement
First, make it easy. Then make it fast. Then make it pretty.
Rationale
When launching a new product cost are high. Making a good performing product is complex and expensive. So when working on a MVP, try to make a product easy to use and easy to create. Focus on UX.
Implications
Difficult back-end performance and scaling issues are handled later. This can increase development cost if performance is never accounted for in a design.

Use Open Data, Open Standards, Open Source, and Open Innovation


Statement
Use Open Data, Open Standards, Open Source, and Open Innovation
Rationale
Too often in international development, scarce, public resources are spent investing in code, tools, and innovations that are either locked away behind proprietary, fee-based firewalls, or created in a bespoke way for use in sector-specific silos.  This principle: Use Open Data, Open Standards, Open Source, and Open Innovation provides a framework to consider an “open” approach to technology-enabled international development.
Implications
  • Adopt and expand existing open standards.

  • Open data and functionalities and expose them in documented APIs (Application Programming Interfaces) where use by a larger community is possible.

  • Invest in software as a public good.

  • Develop software to be open source by default with the code made available in public repositories and supported through developer communities.


Strategic focus


Statement
Investment decisions are driven by business requirements
Rationale
Core government needs and priorities should be the primary drivers for investment. Investment decisions should be defined by the agency’s vision and strategic plans as well as the requirements of the business. These should also take into account whole-of-government strategic guidance. A business-led and business outcome-oriented architecture is more successful in meeting strategic goals, responding to changing needs and serving consumer expectations. Government service requirements will define any required technological support.
Implications
Agencies need to align with whole-of-government strategic direction. • Agency’s strategic plans need to align with whole-of-government strategic direction. • Investment decisions should be made in accordance with the agency’s vision and strategic plan. • Changes to processes, applications and technology should be made in response to an approved business initiative. • Design of business solutions will need to be aligned with, and traceable to strategic goals and outcomes. • Services, processes and applications will need to be designed from the perspective of the service user. • Building or redevelopment of applications and solutions will be undertaken only after business processes have been analysed, simplified or otherwise redesigned as appropriate. • Applications are delivered in a collaborative partnership with the business owners to enable solutions to meet user-defined requirements for functionality, service levels, cost and delivery timing.

Make things open: it makes things better


Statement
Make things open: it makes things better
Rationale
We should share what we’re doing whenever we can. With colleagues, with users, with the world. Share code, share designs, share ideas, share intentions, share failures. The more eyes there are on a service the better it gets — howlers are spotted, better alternatives are pointed out, the bar is raised. Much of what we’re doing is only possible because of open source code and the generosity of the web design community. We should pay that back.
Implications

Maximise Benefit to the Enterprise


Statement
Information management decisions are made to provide maximum benefit to the enterprise as a whole.
Rationale
This principle embodies ‘‘service above self ’’. Decisions made from an enterprise-wide perspective have greater long-term value than decisions made from any particular organisational perspective. Maximum return on investment requires information management decisions to adhere to enterprise-wide drivers and priorities. No Organisation Unit will detract from the benefit of the whole. However, this principle will not preclude any Organisation Unit from getting its job done.
Implications
Achieving maximum enterprise-wide benefit will require changes in the way we plan and manage information. Technology alone will not bring about this change. Some organisations may have to concede their own preferences for the greater benefit of the entire enterprise. Application development priorities must be established by the entire enterprise for the entire enterprise. Applications components should be shared across organisational boundaries. Information management initiatives should be conducted in accordance with the enterprise plan. Individual organisations should pursue information management initiatives which conform to the blueprints and priorities established by the enterprise. We will change the plan as we need to.

Maximize Benefit to the complete enterprise


Statement
Information management decisions are made to provide maximum benefit to the enterprise as a whole.
Rationale
Decisions made from an enterprise-wide perspective have greater long-term value than decisions made from any particular organizational perspective. Maximum return on investment requires information management decisions to adhere to enterprise-wide drivers and priorities. No minority group will detract from the benefit of the whole. However, this principle will not preclude any minority group from getting its job done.
Implications
Application development priorities must be established by the entire enterprise for the entire enterprise. Strong enterprise governance is required. Information services should be shared across organizational boundaries. Information management initiatives should be conducted in accordance with the enterprise plan. Individual organizations should pursue information management initiatives which conform to the blueprints and priorities established by the enterprise. We will change the plan as we need to.

Reliability


Statement
Information and information systems are reliable, accurate, relevant and timely
Rationale
The take-up and use of lower cost channels will depend on users of services trusting the ability of the organization to provide reliable, accurate, relevant and timely information to consumers.
Implications
Good processes create good data. Processes will need to be the focus of ongoing continuous improvement (which in turn will improve reliability, accuracy, relevancy and timeliness). Our organization needs to deliver information which customers can rely upon.

Reuse and Improve


Statement
Reuse and Improve
Rationale
As the use of information and communications technologies in international development has matured, so too has a base of methods, standards, software, platforms, and other technology tools. Yet too often we see scarce resources being invested to develop new tools when instead existing tools could be adapted and improved. This principle: Reuse and Improve highlights ways that adaptation and improvement can lead to higher quality resources available to the wider community of international development practitioners.
Implications
  • Use, modify and extend existing tools, platforms, and frameworks when possible.

  • Develop in modular ways favoring approaches that are interoperable over those that are monolithic by design.


Reuse before Buy, Buy before Build


Statement
Prior to acquiring new assets, the company will reuse applicable existing information and technology assets. If no existing internal asset is available for reuse, the company prefers to acquire, by purchasing or licensing, applicable externally available assets. The company least preferred option is to custom build a new asset.
Rationale
  • Reusing IT assets (for example, IT systems or data) that are already available is often the simplest, quickest, and least expensive solution, assuming that the IT assets in question sufficiently fit the intended purpose.

  • It is less expensive to buy standard IT solutions than to custom build them, as long as they are not adapted and maintenance is left to the product supplier.

  • Many authoritative data sources make their data products available (or offer data acquisition / generation services), reducing the company’s need to generate such data itself.

  • Custom development of IT assets is often very expensive to sustain.


Implications
  • When functionality is required, existing IT assets in the organization must be evaluated and used first, unless they do not exist and/or are a significant mismatch to the required functionality.

  • To ensure that IT assets are being reused as much as possible, business areas must be prepared to adapt to existing solutions that provide adequate functionality, particularly in situations where the accountable governance body does not deem that business area’s practices to be required to be different from industry standard practices.

  • The company will prefer COTS products and particularly those that are configurable. Some products are so configurable that there is little difference between extensive configuration and custom development. The company y must clearly understand when configuration equates to custom development (that is, the level of configuration is so high that the COTS solution is essentially the same as custom development). In these cases, the scenario will change from buy to build.

  • Agreements or licenses to use data may have legal implications and legal consultation should be part of the process of deciding to use a new data source.


Routine Tasks are Automated Where Appropriate


Statement
Routine tasks that can be automated are automated, where the benefit justifies the cost.
Rationale
  • Routine tasks require relatively little specific knowledge and can be automated fairly easily.

  • Automated tasks are more cost efficient and timeefficient, and less errorprone, than manual tasks.

  • Employee capacity requirements can be optimized, freeing them up to focus on more complex activities.


Implications
  • The knowledge required to perform certain tasks is analyzed and embedded in an IT system when it can be easily formalized.

  • Nonroutine tasks may not be automated.

  • Individual performers will need to be able to automate their own tasks. Business areas should integrate automated work flows, where one business unit receives another business unit’s automated output as its input.


Give before receiving


Statement
Give before receiving
Rationale
Giving is the only way to establish a real relationship and a lasting connection. Focus solely on what you can get out of the connection and you will never make meaningful, mutually beneficial connections and a sustainable business
Implications
Invest time and money in all stakeholder relations.

Information Management is Everybody’s Business


Statement
All organisations in the enterprise participate in information management decisions needed to accomplish business objectives.
Rationale
Information users are the key stakeholders, or customers, in the application of technology to address a business need. In order to ensure information management is aligned with the business, all organisations in the enterprise must be involved in all aspects of the information environment. The business experts from across the enterprise and the technical staff responsible for developing and sustaining the information environment need to come together as a team to jointly define the goals and objectives of IT.
Implications
To operate as a team, every stakeholder, or customer, will need to accept responsibility for developing the information environment. Commitment of resources will be required to implement this principle.

IT Responsibility


Statement
The IT organisation is responsible and accountable for owning and implementing all IT processes and infrastructure that enable solutions to meet business-defined requirements for functionality, service levels, cost, and delivery timing. Decisions should always align back to the requirement of the Business.
Rationale
Effectively align expectations with business requirements and our overall capabilities so that all projects are cost-effective and can be completed in a timely manner. Efficient and effective solutions should have reasonable costs and clear benefits relative to the business proposition.
Implications
The IT function must define processes to manage business expectations and priorities. Projects must follow an established process to reduce costs and to ensure the project has a timely completion. Data, information, and technology should be integrated to provide quality solutions and to maximise results.

Ease-of-Use


Statement
Applications are easy to use for end-users and administrators.
Rationale
The more a user has to understand the underlying technology, the less productive that user is. Avoid mistakes due to difficult comprehension interaction with a system. Most of the knowledge required to operate one system will be similar to others. Using an application should be as intuitive as driving a different car.
Implications
  • The underlying technology is transparent to users.

  • Training is kept to a minimum, and the risk of using a system improperly is low.

  • Default (de-facto) GUI’s are used for interacting with the system.

  • No large user manual is needed.


Be Collaborative


Statement
Be Collaborative
Rationale
The saying: “If you want to go fast, go alone. If you want to go far, go together.” is attributed to an African proverb, but could easily be a mantra for technology-enabled development projects. The principle: Be Collaborative suggests strategies for leveraging and contributing to a broader commons of resource, action, and knowledge to extend the impact of development interventions.
Implications
  • Engage diverse expertise across disciplines and industries at all stages.

  • Work across sector silos to create coordinated and more holistic approaches.

  • Document work, results, processes and best practices and share them widely.

  • Publish materials under a Creative Commons license by default, with strong rationale if another licensing approach is taken.


Business continuity


Statement
Business continuity of Corporate activities must be maintained, despite IT interruptions.
Rationale
Hardware failures, natural disasters, and lack of data integrity must not interrupt business activities.
Implications
- Recoverability, redundancy, and maintenance must be approached at inception. - Applications must be assessed regarding criticality and impact on the company’s mission to determine which continuity level is required and which corresponding recovery plan must be implemented. - A business continuity plan must be present/developed.

Business Principle


Statement
These architectural principles will apply to all organisational units within the enterprise.
Rationale
The only way the University will be able to provide a consistent and measurable level of appropriately robust, reliable, sustainable services and quality information to decision-makers, is if all stakeholders abide by the University’s overarching principles for its technology, information and business architectures.
Implications
This fundamental principle will ensure inclusion, consistency, fairness and continual alignment to the business. Without this the management of our technologies, information and business processes would be quickly undermined. Business Partners engaging with the business will work to find accommodation between interested parties around any conflicts with a principle relevant to the proposal.

Business architecture templates

Creating a business architecture means doing real business research. However for a quality business architecture it make sense to make use of a draft template. From a template you can easily add, remove or change subjects that need special attention within your context. Also since architecture documents always should be created for a clear business goal and to be used by different stakeholders, all quality documents SHOULD contain some default reusable text blocks.

Using business viewpoints

Viewpoints can provide benefit to address specific concerns for certain stakeholders. Below a list of most used viewpoint within a business architecture:

  • Motivation view: describes what the business achieves for itself and its stakeholders (direct and indirect value).

  • Capability view: describes how the business delivers direct and indirect value in response to the challenges of the environment.

  • Activity view: describes the day-to-day behaviour of the business.

  • Responsibility view: captures the relationships between individuals and organizations in terms of responsibilities and commitments. These  relationships and organizational interfaces may be represented as business services.

Help for creating a business architecture