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.

The joy of agile

With the design set in wood, I can now start build a new layout.

I start with a recap of the last article, just enough high-level

• Size

• Scale

• 2-rail or 3-rail system

• Analog or digital train control

• Time period and country/region

• Prioritization, trains and/or landscape

• Budget and/or time

Size is 240x120 cm due to limitations of space, and standard size for birch plywood board.

Scale is H0 due to everything i have, e.g. technical debt.

3-rail system with Märklin C-track as this is what I have and makes track layout simpler. Also technical debt.

Digital train control as I have many trains to run the same time.

Timeperiod is era IIIb in Western Germany (FRD), e.g. 1960-1967. A time period with stream, diesel and electric locomotives. My father lived in Germany partly during that time, so there is a personal connection as well. Even more technical debt.

Priority is running trains, with some landscape, even if landscapes was more important during my childhood. May change over time.

Budget is less of constraint compared to time.

The baseboard

The baseboard is the platform for your model railroad, and were everything start. The physical dimensions set the limits of how much you can expand your layout in space.

This means that within those ramifications we can be agile.

Hold your horses

I didn’t say it's easy to build a complex layout, even if we have a couple of design guidelines.

Remember the layout on the kitchen table?

We could run two short trains, with a third locomotive at the shuttle yard.

The goal here is to have ten trains with more than fifty cars, plus shunting locomotives, running at the same time on the layout. Both longer passenger trains and freight trains. Not forget a bit of a landscape.

How do you solve this problem?

More tracks is the obvious answer, but we still have the limited size. There is only one answer to this problem, and it is building in layers above each other, where some tracks are hidden and some are visible.

You may ask, is it doable?

To quote Pippi Longstocking, “How should I know, when I've never tried?”

Step by step

First of all, I got a track planning book and I begun to build some of the layouts there to get a feeling for the craft and run trains to learn how manage digital control.

Then it was time to create something new, my own layout. Not starting from scratch, I took inspiration from two different layouts and merged them together.

As I didn't have all the tracks for such large large layout, I used a CAD program to design the track plan, so I had a shopping list.

The first version of the layout had two layers and I built out a temporary model with more plywood.

Why?

This is a proof of concept where I could test the traffic on each of the two layers, before building any permanent. I also bought parts for digital control of the trains, as the ambition is to have several trains running autonomous.

The last hurdle in the design is the third layer, a shadow station. Something I never done before. The purpose with this is to have a parking lot for trains waiting to run on the visible parts of the layout.

Here the benefit of CAD software was really high, as we model in 3D and the physical layout is complex with grades, tunnels and lots of tracks. Not forgetting all sensors for digital control.

Next step is a final test of the tricky part of the lowest layer, the helix to the visible layer. You see it in the lower right corner of the 3D model.

Afters this is time to build the permanent layers and lay all tracks. Then the shaping of the landscape with all buildings can begin.

The caveat was that I had to redo the baseboard to be slightly larger 244 x 122 cm, and creating four sections for easier transport instead of one large piece.

So far, this is the only big design mistakes I did. But because I did the model in an agile step by step approach, with tests part by part, not the full layout, the consequence were not so huge. A few hours of extra work and some extra wood.

So far, budget overrun, but more model railroad and rolling stock faster than I anticipated.

Final thoughts

When you need to do some planing and high-level design, to do something simple as a model railroad, albeit a complex one with some limitations.

Do you really think that you can do a large transformation program without some high-level planning, design and guidelines?

Without experience of doing this before?