Autonomous architecture - solution approach

- This is a draft article for review. Structure and content may be updated as this is a complex topic.

If you are an independent film producer today, you need to manage distribution. You also need to work for others. Thus three business models for my company.

Initial phase

When we have different lines of business, I always start with a holistic view. The whole organization, Enterprise wide. I also look at all aspect areas, business, information, application and infrastructure. But this is not enough, as more things are importance. In this example I'm adding governance, security and sustainability as mentioned in IAF. Why sustainability you may ask? You need to manage sustainability to have grants for film production in the future.

What I do is then to use parts of IAF to define the needed architecture views.

Architecture views

The business model canvas for each of the business units is the obvious starting point, and I begin to identify what differs.

Next step are the main capabilities or processes (L1) for the organization. I have defined sixteen capabilities so far and have a mix processes from APQC, TM Forum and bespoke process for film production.

In addition to capabilities and processes, I use TM Forum SID model as a base for the information architecture.

When we have this enterprise architecture on the highest level, we can focus on the actual business need. To be better at film distribution.

Business scope

The six capabilities I would focus on as they differ a lot are:

• Product management

• Platform management

• Supply chain

• Marketing

• Sales

• Customer support

We have two very different products. One is a produced film, to be distributed to an audience. The other type is crew and equipment for film productions.

Platforms, the tools for filmproduction, differs vastly from the distribution platforms, but they need to work seamlessly in real time when we are doing live productions.

Supply chain between film production and film distribution are also totally different. The output from the production is input in supply chain for distribution.

Marketing is often half of the cost for a film production, and targeting the audience. Marketing for film production and provide crew & equipment have a completely different strategy.

The way we sell productions and provide crew & equipment is streamlined today in our CRM-system and works well, but we don't have an estimated process for selling movies to B2B or B2C.

Today, we have functional mailboxes for handling customer support, but we need better processes and tools for this capability, thus in scope for.

How we work differs a lot between the BU, but another question is if the three BU’s use the same information.

Information architecture

Most of us (readers) work with IT, information technology, but the main focus is often on technology, not the information.

What I would focus on is business terminology, information models and data entities in the IT systems, and how they relates.

We leverage the information model from TM Forum, i.e. SID, as the organizations members work with telecom, media and entertainment.

If we look at the product model in SID, the model can manage films, crew, equipment as well as bundles. You can sell both digital and products, or offer subscriptions.

Customer model caters for both B2B and B2C customers, and is a subset of party that also manages suppliers, partners and other organizations that interact with us.

The question is then, how will the information model be used by the processes and implemented in IT.

Does existing systems support an improved distribution process, or do we need to do some changes? What should be could and should be shared between the different business units.

Next steps

To find out, I need to make an information model with business terms, information objects and data entities.

Previously, I've avoided this for my company as it takes too many weeks. Today, I can do this much faster with assistance of AI and it is much more feasible and this will be my next activity.

Next article will be about finding out the gaps between the business architecture and how the IT-system works to find out what's possible. Stay tuned.

Autonomous architecture - problem description

Background

I’ve got three different lines of business; Film production, film distribution and and provide crew & equipment to others. They all end up in the same annual report today, but could belong to many different legal entities in the future.

Distribution business today relies on very manual routines, we need to do something to scale up this business unit. We can’t be profitable otherwise.

If we look at the business model canvas, some parts are overlapping and some parts are not.

Business and IT complexity

Film production and provide crew & equipment are more similar than film distribution. The first two are B2B only and distribution is both B2B and B2C.

With film production, we are responsible for the whole process or parts of the process. When we provide crew and equipment somebody else have that responsibility. In both cases, we need to keep track of resources and when they are booked or not.

With distribution, we sell digital availability of films to customers, direct or indirect, and we need to manage rights to different regions.

The core processes (partly APQC) mostly differs between the three business units, but supporting processes (APQC) are more common.

The business terms differs to a certain amount, but we could probably have the same information model for all three units, based on TM Forum SID-model.

We are using Visma for finance, CRM and high-level resource planning. Yamdu is used for pre-planning and production of films. Office 365 as document repositories and collaborations.

There are also lots of specialized tools for the whole film production process.

It is possible to use SalesForce as a standalone CRM for distribution business from a B2B perspective. The question is how to manage B2C sales of film and live events.

Question

The question is how this impacts the architecture, what constraints we have from our technical debt and how the organization is setup.

We basically have three options

• 100% separate systems between each business unit

• Common systems for all business units

• Some common systems and some separate

First one is simple. Second a vision, but seldom realistic, not even for a small organization. For the third option the big question is how to split and integrate.

The approach for this will presented in the second article.

Where is your showreel?

If you're in the film business, you have an entry in IMDB and probably a showreel, but for us working in the private sector with consulting, this is not as easy.

I've been a consultant for more than thirty years, and I'm normally not allowed to talk about my clients or any details of what I've done in public. In some cases, even my managers don't know what kind of project I'm in.

If you are a software developer, you can publish code that is open source. Either in a commercial project or as a side-hobby. But if you have other roles, it's hard to show your best side in the sun. It's less tangible and we often work in groups together with others. As an Enterprise Architect is it even harder to show what you have done or the benefits with your work. What I see from others are often theoretical essays or promotion of tools & frameworks. Very litte of how they do their work or examples of real stuff. I partly understand why.

For whole my career, I've been trying to improve how people work, with IT. Very practical, not so much about theory. However, you need theory to be able to solve complex problems, but it's not the main point. If you are an Enterprise Architect, IMHO, you must be able to do work in real projects.

I begun blogging at disruptive architecture to share my experiences from the changing enterprise and trying to give typical examples, based on generic client stories. The EA-case study was the next step. In this series of articles I show the real architecture for my film production company and how I think. Another example is Agile city planning in small scale, where I use architecture thinking combined with agile m1ethods at a model railroad layout.

You may laugh at these to examples as they are not big company architectures. Fine with me. It's easy to be an armchair quarterback. I'm waiting to see you publish something real. Until then I rest my case.

A very obvious comparison of LinkedIn and horse riding is, when you're in the saddle, the only thing that matters is your performance.

(Yes, I'm on IMDB and I have published open source code.)

Partner in crime

Who is accountable in a large transformation program? We are talking about budget, time and quality of solution. The classic triangle in all projects.

There are three caveats with this question.

The first is the scope of the program. Is it end-to-end, both business and IT in scope? Second, does the program manager have the knowledge and time to do the work needed as accountable? Last, but not least is the conflict of interest. You wish for time, budget and quality and you very often have to give at least of them lower priority.

Unless the program is only a 1-1 technical upgrade, you must include business operations and how business have to change their ways of working. The scope for then end-to-end solution must be both business and IT. It doesn't help much either to outsource accountability to a system integrator or other third party. You own your business.

I've been accountable as project manger and architect in a medium size implementation project, (11 months and 2.5 M€ budget, not including hardware or internal time. In this project, I was accountable, but also as Anne Lapkin mentioned, I had the authority to take decisions, given by the steering committee.

As we delivered on time, within budget and quality, why don't I always continue to work like this? The reason is that this is two demanding roles and I worked 80h per week most of the year, which is not sustainable in the long run.

A few years later I was involved in another international project where I had both roles, PM and EA. When the stakeholders wanted the scope to increase, I said no, as the effort would be to high, but also due to internal politics, that make the PM & EA work even more difficult.

The second is more subtle. In larger programs, we often have more complexity and there are always different trade-offs we have to do to have and end-to-end solution that fits within budget and time. A solution that consists of several solution architectures and the responsibility of each solution architect.

In the best case, a project manger have learned a project method, but those methods focus on time and budget, not how to design an end-to-end solution.

Ad-hoc doesn't work in large programs, and agile doesn't scale when we have to many depencies in the program. We must therefore use a method for designing end-to-end solutions. A method we often call Enterprise Architecture. A version that needs to be adapted to programs and not high-level company strategy, e.g. Ivory tower EA.

Very few project managers have the skills of an enterprise architect. Even if they done smaller projects before, large programs are of a very different magnitude and require different skills.

Have you played chess with yourself?

It's very difficult to be your own opponent and question your own priorities and decisions. In this case two heads are better than one and will result in 1+1 > 2. It's both about priorities and have a sparring partner for your thoughts. This is also why the personal chemistry between the PM and EA is important, as they have to work very tight together and share the same values.

To succeed in larger projects, my recommendation is to to have two roles, project manager with responsibility for time and budget, and a technical project manager responsible for the solution. It aligns very well with what we teach at Capgemini, one Engagement Manager and one Enterprise Architect in programs with accountability.

Architecture principles revisited

Do you really need architecture principles? If they state the obvious or doesn't help you design a solution, why bother?

We go back to our model railroad example where we need to do some high-level decisions. Which principles do we need to guide our city planning in small scale?

I listed seven questions to be resolved before you start, but are they principles, or related to principles?

• Size

• Scale

• 2-rail or 3-rail system

• Analog or digital train control

• Timeperiod, e.g. era and country/region

• Prio of building landscape or running trains, or both.

• Budget, or more time.

Is size a principle? It's very difficult to create a layout larger than your available physical space, unless you make modules to switch between. Thus no principle.

What scale to use? If you try to match different scales, they don't fit together, so you need to select one. Devils advocate here. You can have two non-connected tracks on a layout with different scales. In the real world you have narrow tracks, so some variations are allowed. Buildings are not always in scale 1:87 but a tad smaller. If you mix H0 with N-scale, the result will be less real. Neither a principle.

2-rail or 3-rail system? You can't run locomotives for 2-rail on 3-rail tracks, or vice versa. But you can run cars manufactured for 2-rail on 3-rail systems. More option with 2-rail system and more realistic, but less simple. No principle either.

Analog or digital train control is also a choice to make. You can't mix track sections for analog and digital, so either of one if you don't do two different layouts as different gauge. Not a principle.

Time period and country/region is a bit different. You can mix time-periods if you want, and there are creative ideas how to make this realistic. You still can see old steam engines running on the tracks as today. Trains and wagons also cross borders. Time period is not a principle per se, but strive for realism could be a principle

Prioritizing modelling or running train, including level of ambition would be different, depending on the person who is paying and her objectives.

Budget and time are not principles, they are constraints in the same way as size of your layout. You need to manage them.

What could then be the principles that help you with the design? Here are some suggestions based on my trials the last year.

1. First of all, have fun, this is a hobby.

2. Strive for realism, not mixing things that wouldn't be plausible in real life.

3. Avoid symmetri is another principle related to realism, as nature is not symmetrical.

4. Have a reason, a purpose, for your locomotives and wagons.

5. Design for accidents with rolling stock and other problems.

6. Build to avoid traffic congestions.

7. Build before buy is an option today with the arrival of 3D-printing.

8. Build in modules is another principle that makes your model railroad more scalable and flexible.

9. Build you landscape step by step, not a big bang.

All these suggestion of principles help you with the design of the layout and what to buy for your personal taste. You may not agree, that's fine. But it's good with principles that are relevant for you and your own city plan.