First a foreword to this and following articles in the EA case study series.

Regardless of architecture framework you use, don’t overdo your work. Use only artefacts and views needed to solve your problem, and limit your effort by focus on the area where you have most benefits.

In this example I will use IAF, as this is the framework I have been using for twenty years. This is not a description of the framework per se, instead it’s an example of how I use an architecture framework, in this case IAF.

If you prefer another framework and think it’s superior to this one, fine. Just do it, describe the same business as I do with your model if you like. You can use the information provided for non-commercial use, and with a reference to this site.

This is the first properly documented Enterprise Architecture for our company and the work with it started in late summer when we migrated to Microsoft Office 365.

Prior to this, we had a business processes for film production of feature films documented in a production handbook, and the documentation needed for a rudimentary “GDPR compliance”.

The main reason for us doing the enterprise architecture work is to improve how we make better and better stories together, e.g. Business Development. It’s more fun to do film than architecture.

Update: Business Need changed to Capability and detailed Business Need was changed to Business Events to be consistent with latest version of IAF.

Contextual layer

In IAF is the contextual layer the section where you put things related to why (and why not)

Business Vision and Business Mission is described earlier and act as input to the architecture.

We talk about Capabilities, Stakeholders, Architecture principles, Constraints etc. on a high level, common for the whole organisation and it’s eco-system.

Without this part, it’s not possible to do a proper architecture as you don’t have a context to put it in. It will just be a generic architecture on a to high level.

My recommendation is to use the Business Model Canvas as input the contextual layer together with other strategic documentation and organisation schemas even if they not are explicitly stated in the IAF-model.

Capabilities

The challenge with business need for a startup, but also a large transformation is to define Capabilities on a manageable level.

My recommendation is to use a not to large set of capabilities for an enterprise wide architecture. I often use prioritised Business Events from a business standpoint, but also in different areas of the organisation.

In our case, we focus on Production of Film, Video and TV, Sales and HR as they were Key Activities in our canvas. As previously written, not all productions are the same, and we have to describe several different capabilities dependent on type of production.

The process name in parenthesis after the need is used to categorise business events in different areas. In this case we have a functional organisation and therefore processes works good as area concept, i.e. capabilities.

Business events in bold text below is where we have to prioritize our effort, eg. Architecture scope, in describing business processes and IT-support. The other needs are there as a reminder of other processes we need to manage, but we assume that we don’t need the details yet.

Production of corporate video (Production)
Production of a commercial video (Production)
Production and distribution of a live event video (Production)
Production of a feature film (Production)
Provide crew to a production (Sales)
Sell a smaller production (Sales)
Sell a larger production (Sales)
Report statistics about distributed content accordingly to regulations (Management)
Send an invoice to a customer for worked hours and expenses for crew in a production (Invoice)
Send an invoice to a customer for fixed fee projects with rental costs included (Invoice)
Request for personal information, e.g. GDPR (Customer support)
A Customer raises a problem in a production (Customer support)
Security incident with impact on personal data (IT)
Hire a contractor for a production (HR)
Time and expense reporting for both employees and contractors (HR)
Hire equipment for a production (Supply chain)

Wi will for sure find more Capabilities, more Business events and change priorities, but this is a good start.

Update: Business Events is part of conceptual layer in latest version of IAF.

Stakeholders

In a small company is stakeholder management fairly easy compared to large organisations. Right now wee see three groups of stakeholders.

Management group
Employees and contractors
Key partners

We see Key Partners as stakeholders, but we have not added Customer Segments as stakeholders. Why?

The reason is that in many cases are production companies, distributors etc. also investors in the productions, and thus included in the list of stakeholders.

Architecture principles

Keep it simple is my recommendation for architecture principles. To many of them and people will not remember and follow them. The list below is on a high level and probably sufficient for our need.

Cloud first
Autonomous systems
Avoid use, re-use, rent, buy, develop
Do not rely on only one option for suppliers of business critical applications
Design for end of life for applications, not the data
Privacy by Design & Privacy by Default
Design for VUCA (Volatility, uncertainty, complexity and ambiguity)

Cloud first as we don’t want to manage infrastructure if possible.

We often use niche software, and if the supplier of one reason or another decides to bin the product must we have another alternative instead.

Design for end-of-life for applications is because we work with copyrighted material and the life time of this is at least 50 years but often more.

Don’t underestimate the effort needed to follow the principles for Privacy by Design & Privacy by Default or VUCA then designing your architecture.

Assumptions

The list of assumptions relies in the contextual layer, as well as constraints and risks. For me this is part of normal project management, but this is what we think is related to enterprise architecture

Possibility to improve existing workflow in production and other processes, thus delivering faster and to a lower cost with same or higher qualify

Constraints

Rules for grants in production of narratives
Limited capacity in resources during startup phase
High speed bandwidth at a reasonable cost at all locations

Risks

Stakeholder commitment
Our assumptions about possibility to improve are wrong
Long term profitability in the business
Swedish/Nordic market may be to small for film production in the long run

We are trying to do things different and involved parties need to change how they think and how they work. This is why stakeholder commitment is the main risk.

The other risks are more related to the market.

Disruptive architecture