Andreas Amundin

Portfolio

Enterprise Architecture

PrimaryScape

Andreas Amundin

My name is Andreas Amundin. I am an enterprise, business, and technology architect with 17 years of experience. My current focus is on outcome oriented and reality based architectures for enterprises, businesses, organizational units, projects, and large scale programs.

I am the creator of the PrimaryScape modeling notation. This is a new modeling notation which makes it easier to describe outcome oriented and reality based architectures.

Over the years I have worked both as a consultant and employee in roles including:
  • enterprise architect
  • business systems architect
  • applications architect
  • integration architect
  • software architect
  • professional trainer
  • business analyst
  • technical lead
  • software developer
My experience includes but is not limited to:
  • enterprise/business/technology architecture
  • business information and data modeling
  • business process management/modeling
  • enterprise application integration
  • capability modeling
  • functional decompositions
  • use case based requirements
  • object oriented programming and design

View Andreas Amundin's profile on LinkedIn Andreas Amundin On Architecture PrimaryScape

Portfolio

Federated Architecture
PrimaryScape Simple Example

Portfolio Content

Each of the thumbnails above will bring up a different slide show containing examples of my work.

In these work examples the focus have been on showcasing architectural diagrams.

Please note that architecture is much more than just pictures. When available, I have included links to published content where more information about the work can be found.

  • Federated Business Systems Architecture

    The goal of describing a federated business systems architecture was to show how such an architecture would reduce enterprise complexity, increase business ownership, increase clarity of business unit agreements and dependencies, and lay the foundation for enabling an effective enterprise data warehouse capability.

    The key to understanding the value of this architecture is recognizing that business units act locally to their interests and enterprise data warehouse solutions provide global analytic and reporting solutions. This is why business units are less likely to understand why their projects have to be integrated at extra cost and constraints to support an enterprise initiative. Logically everyone will agree that an enterprise data warehouse will add value, but when it comes to their own projects these additional costs and constraints feel unnecessary or unrealistic. A common result is an enterprise data warehouse solution where none of the business unit leaders feel vested in it. Over time such enterprise solutions grow stale due to lack of investment.

    The federated business systems architecture solves for this problem by making sure all the infrastructure to exchange information is owned at the business unit level. Business unit domains establish clear practices for how to exchange information between themselves to support their own local needs. The side effect is that all the information sharing infrastructure is owned and maintained by the business units. This infrastructure can then be leveraged to copy all business unit information into a central enterprise data warehouse. This data gathering effort is owned by a separate analytics team with its own budget apart from the regular business units. The overall work and costs to establish an enterprise data warehouse is spread across the enterprise with each business unit understanding the need for their own infrastructure.

  • A Simple PrimaryScape Example

    This simple PrimaryScape example was created to show the power and simplicity of the PrimaryScape modeling notation.

    In this example, systems are shown together with teams, and processes are shown together with information. This example brings together concepts, which traditionally have been captured separately. Business management tend to focus on teams and processes and IT management tend to focus on systems and information. The power of this example is showing how easy it is to capture all these important aspects using a simple modeling notation.

    PrimaryScape is new modeling notation I have created to make it easier to describe enterprises, organizations, business units, and IT systems. PrimaryScape can also be used to describe the outcomes of projects, programs, and initiatives.

    For more information about PrimaryScape go to the website or watch the introduction on youtube.

View Andreas Amundin's profile on LinkedIn Andreas Amundin On Architecture PrimaryScape

Enterprise Architecture

The purpose of architecture is to create shared understanding.

I consider an architecture to be good if it is understandable by the right people and has an achievable objective. Whether an architecture is good depends a lot on its context. Who are the different people who need to understand the architecture and what aspects does each person need to understand? Is the objective of the architecture achievable given the resources, capabilities, and constraints of the organization? Is the objective of the architecture clearly understood?

The most common objectives of architecture are to inform planning and strategy, to build or change, or to run efficiently. The target audiences for each of these objectives are different which means the architectural artifacts will be different.

The greater the scope, detail, and complexity of an architecture the more architecturally capable the people who has to understand the architecture must be. What is a perfect architecture for an architecturally mature organization will be useless for an organization just starting to develop an architecture competency.

To learn more about my thoughts on architecture please check out my blog On Architecture.

View Andreas Amundin's profile on LinkedIn Andreas Amundin On Architecture PrimaryScape

PrimaryScape

PrimaryScape is new modeling notation I have created to make it easier to describe enterprises, organizations, business units, and IT systems. PrimaryScape can also be used to describe the outcomes of projects, programs, and initiatives.

PrimaryScape is

  • Simple
  • Expressive
  • Easy to understand
  • Scales to any level
  • Helps bridge the Business-IT divide
  • Shows teams together with systems
  • Shows process together with information

The PrimaryScape notation consists of 3 concepts and 4 relationships. The 3 concepts are represented by behavior and information realized in structure. The 4 relationships are data access, data transfer, functional access, and functional transfer.

Together these concepts and relationships can be combined to express just about any kind of system, be it people based and/or computer based.

For more information about PrimaryScape:

View Andreas Amundin's profile on LinkedIn Andreas Amundin On Architecture PrimaryScape