What makes a Smart Factory – Part 2: Deconstruction with Enterprise Architecture

In my previous post, we briefly discussed the concept of a Smart Factory (SF). To recap, the SF was described as a vision of a production unit 1) which can be guided, and 2) which truly is guided by intelligence. In addition, to reach this vision, the ancient Roman approach to divide and conquer was recommended. But how in detail should you go about breaking these two high level SF elements into smaller, manageable and more practical building blocks? Blocks, which you could manage and develop further in order to reach the full Smart Factory vision. And what are the resulting blocks?

These questions are the main focus of this post. I will guide you through how the overall deconstruction looks like using Enterprise Architecture (EA) as your main toolset and how it can be done effectively without independent silos of development.

Can you apply or have you already applied some of these takeaways or EA in general in your own factory operations? Keep reading to see how to deconstruct your SF operations and how you might do the same for your own factory.

This blog post is the second in a multi part series of What makes a Smart Factory (links: part1, part3, part4). I will share links to the next parts when available.

What is operational development?

Today, it is common to hear statements such as ”we’d like to get into the Industrial Internet” or ”we are building a Smart Factory”. These comments should in all cases be interpreted as equal to ”we do business development”. Simple as that. All development in an industrial environment should eventually be treated and thought of as business development. There are no such things as Industrial Internet projects or Smart Factory developments. All development is or should be business development.

As tempting as it may be to launch Internet of Things or Industrial Internet projects, please do not call them as this or at least communicate the true purpose and true goals of your project. Unless you of course want to polish the otherwise-not-going-to-be-approved investment projects 🙂

Operational development is a sub domain of business development and it focuses on daily operations. In a factory, whose scope of responsibility is typically to manage and operate the so called Plan-to-Produce (Pl2P) process, all relevant building blocks are covered by operational development. In contrast to business development, operational development is focused purely on operations and therefore does not cover areas such as company strategy or company culture.

Why should you care?

When conducting business or operational development in a factory environment, the most critical problems most often highlighted are related to communication. Process developers don’t understand IT developers and vice versa. Quality engineers have a problem with IT architects. Mechanical suppliers don’t know how to integrate their systems with ERP vendors. IT initiatives are handled separately to mechanical projects. In order for operational development to succeed, you must improve the way people communicate and ensure they are aligned in their efforts, concepts and language used. Enterprise Architecture provides you with the basic platform for the alignment.

Enterprise Architecture (EA): Capturing the big picture

Do you know what is by far the most popular discussion topic among enterprise architects (I do, after having the privilege to work with such a team for two years)? It is: ”What is enterprise architecture?” Fortunately for us, this is just small talk among the pros – the people working in the field are one the smartest people I know and their methods are diamond sharp.

Enterprise architecture, as Google’s current top search result puts it, is “a conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives.” With EA, you can bridge a lot of those silo or department gaps which typically exist in mapping people, processes and systems between the teams involved in business or operational development.

How you should see it in practice is that EA provides you with robust means how to capture the big complex picture of how your mill operations run, how they are realized and how they are interconnected from different viewpoints. As my former colleague Ari puts it in his excellent “How to get started with EA” blog series: ”EA can be used as a development framework to create the big picture. Showing high level conceptual data flows needed in business operations, and linking your IT applications and technology to business processes lets you see the whole big picture, that is, EA. Having this in place, both business and IT management can make predictable changes to it when needed, and understand the impact to business operations better. Keeping things simple and high level enough, enterprise architecture can be a valuable tool for both business and information management.”

The role of EA in summary is to lay out the map for the as is and to be Smart Factory operations and to highlight the various viewpoints’ relationships as a complete architectural model.

In detail, this map is usually delivered as a visualization of the architecture containing four key domains with their interrelationships:

1. Business architecture (think production people, organization, strategy, capabilities, processes),
2. Information architecture (production data),
3. Application architecture (production applications and software) and
4. Technology architecture (factory equipment, hardware and buildings).

Image courtesy of QPR Software Plc

To have a look at how the captured deliverables look like when modeled with modern EA systems, see e.g. this video clip from QPR Software.

Enterprise Architecture frameworks, methodologies and tools

For practical support in EA work, you need three accelerators: frameworks (outline of your deliverables), methods (ways to make the deliverables) and tools (to help make the deliverables according to the framework).

EA frameworks

An EA framework defines how to create and use an enterprise architecture. You can get started also without a framework, but to get a quick and tried way of modeling your own Smart Factory visual EA map ready for action and understandable to all, I strongly recommend utilizing a publicly known EA framework such as TOGAF (dozens of alternatives exist, too) and to train your people on it. Especially if there are more people on the job, it eases your work tremendously having a common way of modeling.

Image courtesy of Technology Training Limited

EA development methodologies

In addition to the Smart Factory architecture framework (= map layout template), I recommend also selecting the methods and tools for the actual EA work. Here again, it is not worthwhile reinventing the wheel but to check out for example TOGAF ADM, the number one method in case you use TOGAF in your architecture work.

Here’s a comparison of the top four EA methodologies presented.

EA tools

What tools have you used earlier to model processes or more complex process – system integration scenarios? And which systems to document your IT systems? I’m betting on MS Office (Visio, PowerPoint, Excel, Word), which more than 80% of companies use in their improvement initiatives.

There are however a number of more fit systems available for EA development. Examples of these tools can be found e.g. in Gartner’s magic quadrant for Enterprise Architecture Tools:

Image courtesy of Gartner Inc

Got it – what’s next?

Now that you know the basic approach of effectively capturing and modeling the different building blocks of a Smart Factory using EA, you are able to start your factory development in an integrated way (vs. an isolated siloed way often leading to trouble).

In the next posts of this series, I’ll take you through the various domains of EA (business, information, application, technology) relevant for Smart Factory development. The walkthrough of these domains will cover the detailed activities, methods and tools involved to support development and will give you practical tips on how to start actual work.

What do you think makes a factory ”Smart”? How would you start working on it? Do you have experiences to share with Enterprise Architecture?