CloseReach and QualiWare invite you to join us for the 3rd annual QualiWare + EA Professional Development Days. An event to promote networking, learning and collaboration for Architects and QualiWare enthusiasts, novices and experts alike.
Meet other QualiWare users, Business and Enterprise Architects, Project Managers, Analysts, BPM Specialists and Quality Managers. Share architecture and QualiWare experiences. Learn from customer case studies. Take part in interactive ideas exchanges. Influence product development.
Building on the success of 2016, we will be expanding your opportunities for learning and knowledge sharing. Join us for this excellent professional development opportunity:
Speakers Day (Monday) – the best place to hear about the latest developments in enterprise architecture and business transformation in Canada and globally. Speakers Day early bird pricing is in effect: $250 per person, 5-pack: $1,125.00, 10-pack: $2,125.00. HST extra. Includes a great day of speakers as well as breakfast and lunch.
Kuno Brodersen – EA and Digital Transformation Strategies
A leader in the business modeling and enterprise architecture field for more than 30 years.
CEO and Co- Founder of QualiWare ApS. QualiWare provides comprehensive modeling tools and consulting services that focus on enhancing business efficiency, effectiveness, productivity, competitive positioning, and organizational profitability. QualiWare’s products and services help the customer succeed with Quality Management, Process Management and Optimization initiatives, Business Excellence programs, Enterprise Architecture initiatives, and/or IT solution development needs.
Roger Burlton – A Journey from Business Architecture to a Digital Process? A Case Study in Government Transformation
Respected pioneer in the introduction of innovative approaches for Business Architecture and Process Management
A leader in the field of Business Process Management, having authored one of the most read and followed books on the topic early in BPM’s growth.
Chair of the BPTrends.com Advisory Board
Stephen Challinor – Enterprise Architecture as a Business Enabler
Director Enterprise Architecture, Department of National Defence
Co-Chair Government of Canada EA Working Group
27-year career as a public servant with a broad background in complex project and procurement management, weapon systems and equipment management, business and financial management, IM/IT systems and Alternate Service Delivery (ASD) initiatives.
Skip Lumley – Developing and Implementing a Pan-Canadian Standard for Public Sector Business Architecture
Co-founded and managed the consulting firm Chartwell IRM Inc. from 1984 until its acquisition in 2010 by KPMG Canada.
Leader in the development and support of government reference models: the Municipal Reference Model (MRM), the Public Service Reference Model (Province of Ontario) and the Governments of Canada Strategic Reference Model (GSRM).
Currently serving as an independent advisor to public and civic sector organizations on the use of reference models for program review, policy development, strategic planning and change management.
Stephen White – Digitalizing Your Business Processes
Business Process Management Institute (BPMI) Board of Directors
Former Chair of BPMI Notation Working Group and author/editor of Business Process Modeling Notation (BPMN) 1.0 & 2.0 Technical Specification
Chair of OMG Revision Task Force and Co-Chair of OMG FTF for BPMN 2.0
Contributor to OMG CMMN 1.0 specification
Co-Authored Book “BPMN modeling and reference guide”
Tool-Day (Tuesday) – How-To Seminars/Workshops: Business Modelling (BPMN, Capability Modelling, Requirements & Traceability); Collaboration using QualiWare Web Publishing; Change & Problem Management using QualiWare Governance Workflow Engine; Modelling Revision Management, Back-up and Recovery Strategies.
Tuesday seminars/workshops are offered at the nominal (full day) cost of $20.00 + HST per person with 100% of proceeds being donated to the Royal Ottawa PTSD Clinic.
Business Architecture Training (Tuesday-Friday) – “Made in Canada” Business Architecture training & certification with Roger Burlton.
QualiWare Training (Wednesday-Friday) – take full advantage of QualiWare’s EA software
QualiWare Data Visualization
QualiWare Command Language (QCL) Basic.
For more information or advance seating reservations for Speakers Day and all of the week’s events, contact Susan Wolfenden; email@example.com, 613-825-1769. Space is limited – call now!
Please feel free to share this invitation with colleagues. Help us make this event the place to be in Canada for all things architecture related!
We stand on the brink of a technological revolution that will fundamentally alter the way we live, work, and relate to one another. In its scale, scope, and complexity, the transformation will be unlike anything humankind has experienced before.
Klaus Schwab Founder and Executive Chairman World Economic Forum
On our study trip to Automation Valley, we learned about Industry 4.0 and the digitalization of German manufacturing. On the way back to Denmark, one of the other participants said, “yep, the Germans set the standard”. This is indeed the case, even in a very literal sense: They’re making Industry 4.0 a German DIN Standard, and are aiming for international standardization.
a three-dimensional coordinate system that describes all crucial aspects of Industrie 4.0. In this way, complex interrelations can be broken down into smaller and simpler clusters.
The coordinate system is further described as follows:
The “Hierarchy Levels” axis:
Indicated on the right horizontal axis are hierarchy levels from IEC 62264, the international standards series for enterprise IT and control systems. These hierarchy levels represent the different functionalities within factories or facilities. In order to represent the Industrie 4.0 environment, these functionalities have been expanded to include workpieces, labelled “Product”, and the connection to the Internet of Things and Services, labelled “Connected World”.
The “Life Cycle & Value Stream” axis:
The left horizontal axis represents the life cycle of facilities and products, based on IEC 62890 for life-cycle management. Furthermore, a distinction is made between “types” and “instances”. A “type” becomes an “instance” when design and prototyping have been completed and the actual product is being manufactured.
The “Layers” axis:
The six layers on the vertical axis serve to describe the decomposition of a machine into its properties structured layer by layer, i.e. the virtual mapping of a machine. Such representations originate from information and communication technology, where properties of complex systems are commonly broken down into layers.
Together, the axes form a model that can be used as follows:
Within these three axes, all crucial aspects of Industrie 4.0 can be mapped, allowing objects such as machines to be classified according to the model. Highly flexible Industrie 4.0 concepts can thus be described and implemented using RAMI 4.0. The reference architectural model allows for step-by-step migration from the present into the world of Industrie 4.0.
…RAMI 4.0 provides a common understanding for standards and use cases….RAMI 4.0 can be regarded as a kind of 3D map of Industrie 4.0 solutions: it provides an orientation for plotting the requirements of sectors together with national and international standards in order to define and further develop Industrie 4.0. Overlapping standards and gaps can thus be identified and resolved.
RAMI 4.0 is referencing three standards:
IEC 62890 – Life-cycle management for systems and products used in industrial-process measurement, control and automation. Note: Under development since 2013 and not available to the public until its release, scheduled for September 2016.
IEC 62264 – Enterprise-control system integration.
The International Electrotechnical Commission (IEC) white paper on Factory of the Future explains further that when establishing interoperability in manufacturing environments, different dimensions of integration have to be considered:
Vertical integration, i.e. along the automation pyramid as defined by IEC 62264/IEC 61512. This includes factory-internal integration from sensors and actuators within machines up to ERP systems.
Horizontal integration, i.e. along the value chain and throughout production networks. This includes the integration of production networks on the business level as achieved by EDI-based supply chain integration, but might include more in the future, when close-to-real-time and product- or process-specific information is exchanged to increase the level of detail and quality in distributed manufacturing optimization.
Integration towards engineering and product/production life cycle applications (e.g. IEC 62890) in order to enable low-effort knowledge sharing and synchronization between product and service development and manufacturing environments.
Standardizing RAMI 4.0
RAMI4.0 has now been put forward for standardization in Germany as DIN SPEC 91345 – Referenzarchitekturmodell Industrie 4.0. It often takes years for a DIN SPEC to become an official DIN Standard, but now the process has begun, and since Industry 4.0 seems to be a high priority area for DIN, they may decide to fast-track this standard.
So far, the standard is available in German language only, but should be available in English too soon. For now, the most comprehensive publications in English about RAMI 4.0 seem to be the 2016 status report and the 2015 status report.
IEC has put Industry 4.0, including RAMI, high on their agenda. In their call for their general assembly later this year, IEC outlines its future plans and strategic goals for Industry 4.0 reference models and architectures:
Developing a description of the reference models in dedicated standards. As with core models, reference models are also used in a wide variety of model solutions.
Defining reference models separately as independent standards for the purposes of simplification and avoidance of unintentional deviations, and for better understanding.
Implementing a nearly finished specification (DIN SPEC 91345 – publication planned Q2 2016) as Public Available Specification – PAS within IEC, starting with the new work item procedure in the relevant Technical Committee of the IEC.
The relevant IEC committee would probably be TC65 who also owns the three IEC standards included in DIN SPEC 91345, but there are likely many other TCs in IEC who eventually become involved with Industry 4.0. The same will many other standardization organizations and initiatives. The Technical Management Board (TMB) of the International Standard Organization (ISO) has set up a Strategic Advisory Group (SAG) on Industry 4.0/Smart Manufacturing. This SAG should cooperate closely with the International Electrotechnical Commission (IEC) and the International Telecommunication Union (ITU), and is supposed to report back by September 2016. Most of this work takes place behind closed doors, and the SAGs homepage is not very informative.
Analyzing RAMI 4.0’s roots
The “Life Cycle & Value Stream” axis is based on an unpublished standard, and therefore difficult to assess. The 2016 status report shed some light on this, and states that:
It was one of the main design decisions of the RAMI4.0 architecture to model type descriptions as individual assets (with own life cycles) which are independent from specific products. To highlight this fact, the assets are divided along the x-axis into “types” (type descriptions) and “instances” (specific products).
And also, that,
This is just a very rough classification but it helps to separate the development and life-cycle management of product types (product families) from the production and lifecycle management of the individual products.
The distinction between type and instance is classic in software engineering and information modeling. RAMI 4.0 maps the asset categories to the life-cycle dimension and the value stream.
Architecturally, this is an interesting approach. But someone really needs to work on the visualization and explanation of the dimension. The status report hints that the IEC 62890 standard will explain it all.
The “Hierarchy Levels” (with IEC62264) dimension is based on the classic ISA-95 which dates back to the 1990s (but is still maintained).
To create a standard that will define the interface between control functions and other enterprise functions based upon the Purdue Reference Model for CIM (hierarchical form) as published by ISA. The interface initially considered is the interface between levels 3 and 4 of that model. Additional interfaces will be considered, as appropriate. The goal is to reduce the risk, cost, and errors associated with implementing these interfaces. The standard must define information exchange that is robust, safe, and cost effective. The exchange mechanism must preserve the integrity of each system’s information and span of control.
The Purdue Reference Model for CIM (Computer Integrated Manufacturing) from 1989, published as ISA-95, became the de facto organizing logic for manufacturing information systems and defined that the 0-4 levels have core information systems: ERP at level 4, MES at level 3, and SCADA at level 2.
The hierarchy in RAMI 4.0 is divided into two parts: products (and users) and equipment (field devices, control devices, stations, work units, enterprises and connected world).
The status report seems to acknowledge that RAMI 4.0 may not have hit the nail:
All in all, the ordering schema along the y-axis is just a presentation help for fostering an intuitive understanding of the architecture. In case the terms or aggregation steps do not fit into the respective domains, they can easily be readjusted.
serve to describe the decomposition of a machine into its properties structured layer by layer, i.e. the virtual mapping of a machine. Such representations originate from information and communication technology, where properties of complex systems are commonly broken down into layers.
Layering is a classic theme in enterprise architecture. Although there are some critics, most current enterprise architecture frameworks use architectural layers (e.g., strategy, business, information, applications, infrastructure, and security in EA3).
“The nice thing about standards …”
“…is that you have so many to choose from,” Tanembaum‘s old “joke” about standardization, applies here: RAMI 4.0 is not the only standard for digital industry reference architecture.
the open membership, international not-for-profit consortium that is setting the architectural framework and direction for the Industrial Internet. Founded by AT&T, Cisco, GE, IBM and Intel in March 2014, the consortium’s mission is to coordinate vast ecosystem initiatives to connect and integrate objects with people, processes and data using common architectures, interoperability and open standards.
This Reference Architecture is a statement of what the most important Industrial Internet architecture components are, how they fit together and how they influence each other. It reflects consensus on major architecture questions among participants from energy, healthcare, manufacturing, transportation and public sectors.
I will look closer at IIRA in a future blog post.
IIC and Plattform Industrie 4.0 in March 2016 announced that they will work together to align RAMI 4.0 and IIRA – Cooperation Among Two Key Leaders in the Industrial Internet – see press release and blog. They released some initial mappings:
In the end, the panel did not agree on whether there would be ultimately one platform or many. But they did agree that they share a common view on the need to gain an understanding of how things should function and making sure that they interact.
Kris Bledowski from the US-based Manufacturers Alliance for Productivity and Innovationcompared the movements about a year ago:
Bledowski sums it up:
Industrie 4.0 strives to optimize production while the IIC’s research targets returns to any asset
Industrie 4.0 works on standardization whereas the IIC works on enabling platforms that might set future standards
Industrie 4.0 is reactive to a fast pace of high-tech innovation; the IIC proactively pushes the frontier of any internet-enabled application
Generalizing the Reference Architectures
The Purdue Reference Model is a key element in PERA, the Purdue Enterprise Reference Architecture, the early 1990s reference model for enterprise architecture. PERA is an example of what was then called Reference Architectures of type II. Other such architectures were GRAI-GIM and CIMOSA.
a reference architecture for defining, designing and classifying IT applications, systems and infrastructure in the upstream oil and gas industry, downstream petrochemical industry, and for engineering, procurement and construction projects.
We believe that the future of EA is in its ability to develop an interdisciplinary language and theory enabling a concerted and synergistic application of contributions of underlying disciplines (results from management science, systems, industrial, manufacturing and software engineering, IS, Artificial Intelligence, and so on).
GERAM is a valuable baseline meta-framework– to discuss the above, to create new theories, schools of thoughts, integration of engineering practices and tools, explanations of how technologies can be part of EA, methodologies for EA implementation, and Partial and Particular models for re-use.
No doubt that the next generation of enterprise information systems will continue emphasising the need for scalable, reliable, extensible, flexible, highly available and maintainable systems architectures providing ubiquitous, plug-and-play, secure, interoperable and networked solutions to realise smarter and collaborative systems, platforms and ICT infrastructures for all entities operating in a common business ecosystem.
The reference architectures we define and use must reflect our architectural visions. RAMI 4.0 and IIRA are two different visions. Which one will be best? As we architects always say, “it depends”.
The market is moving quickly, and we are constantly being tasked with improving on performance to drive better results and justify our positions. To do this we need to bring in digital technologies to facilitate every aspect of the business, and gather data for analysing performance and finding areas to improve. This goes for everything in your business eco-system: supply chain, customer journeys, back-office support functions, processes, IT estate, and all cross-functional activities. Your competitors are working on this, to varying degrees of success, and you also need to.
With so many projects to work on, and potential investments to make, how do we make sure our digital transformation is successful? And provides the quick results that shareholders and stakeholders demand?
Here’s three steps you can do to lay the foundations for successful digital transformation.
Understand your current landscape and digital technologies
Before bringing in new digital tech, you need to know what you have already, where the gaps are, and what options are available. Each functions’ digital requirements will be evolving constantly, and some can be met with the existing set up. Accurately document your enterprise architecture starting with the IT and process landscape and ensure there is alignment with organisational goals. This will provide visibility on the areas for improvement and the impact of bringing in new digital technologies, and allow you to plan for training programs and transformation activities.
Identify key areas for digital transformation
Digital solutions should support the exchange of information between all people and “things” in the business eco-system. All productive processes should therefore be digitally supported, be an organisational part of the enterprise regardless of geographic location, and the ability to exchange information in execution of a process should be available at all times and in all places. Customer journey maps, capability models, and gap analyses developed as part of your enterprise architecture will enable you to identify key areas for digital transformation.
For example, the new “Digital Hospital” in Denmark has used its enterprise architecture to understand how all people and “things” should link up. The digital hospital has visualised the elements required to support core services such as treatment of patients, and non-clinical logistics,and mapped the knowledge that needs to be transferred at each step. The correct digital technologies to support the knowledge transfer can then be identified and introduced. In this case, it includes the introduction of robots in storage areas to ensure that delivery of correct materials is never more than 20 metres from physicians, and mobile registration for log books.
Create a Collaboration Platform
Digital transformation requires buy-in and cooperation from people spread across all areas of the business. The main reason for failure in transformation projects is lack of commitment from stakeholders. Everyone needs to understand the impact of digital transformation, and how to ensure it aligns with overall goal of the organisation, reasons for change, and what they need to do to contribute. A simple web-platform that provides this information in an easy to consume format, with alerts for outstanding tasks can ensure that people stay on top of transformation tasks and remain committed to the end result: a modern digitally enabled enterprise.
Enterprise Architecture is facing several challenges as a discipline and a practice. In this blog post, John Gøtze outlines four central challenges, and discusses what should be done. He suggests that enterprise architecture management must focus on enterprise collaboration.
The discipline Enterprise Architecture (EA) is at a crossroads, facing four challenges:
The first challenge is to overcome the narrowness of scope of present practice in EA, and re-gain the coverage of the entire business on all levels of management, and a holistic and systemic coverage of the enterprise as an economic entity in its social and ecological environment.
The second challenge is how to face the problems caused by complexity that limit the controllability and manageability of the enterprise as a system.
The third challenge is connected with the complexity problem, and describes fundamental issues of sustainability and viability.
Following from the third, the fourth challenge is to identify modes of survival for systems, and dynamic system architectures that evolve and are resilient to changes of the environment in which they live.
A recent (in-press) peer-reviewed article, Enterprise Engineering and Management at the Crossroads – the result of a collaborative effort between eleven authors from four continents – discusses these four challenges and the state of the art of the discipline of Enterprise Architecture, with emphasis on the challenges and future development opportunities of the underlying information system, and its IT implementation, the Enterprise Information System (EIS).
The article provides pointers to possible radical changes to models, methodologies, theories and tools in EIS design and implementation, with the potential to solve these grand challenges:
The article argues that EA needs to embrace full or broad views of the enterprise as per the original vision of the discipline’s mission that originated in manufacturing (e.g. computer integrated manufacturing systems), and the parallel developments in information systems and software development. This division between information systems, system science, and manufacturing & industrial engineering needs to be resolved as it is still felt today and hampers the discipline of EA as a whole. Any credible development of the discipline must equally cover and explain deliberate change and evolutionary change in a system of socio-technical systems, the production & service to the customer, and the management & control of the enterprise, the technical resources (logistics, manufacturing machinery, communication systems, computer systems), human resources, financial resources, and assets of all other kind (knowledge & information assets, buildings and grounds, and various intangibles).
As EA is moving up the hierarchy from technical to management levels, the language and skill set of its practitioners has to change to better reflect the specific needs and language of the management community. This needs to be reflective in terms of not only language, but also culture. The focus must be on views of the organisation that management science is interested in (People, Capability, Place, Role, Relationships and Trust, Risk, Finance, Brand Strategy, Knowledge Management) rather than detailed, possibly local technical views of the organisation.
A central concern in EA is the development of the information system that implements a coherent, aware behaviour of the enterprise on any scale. It is acceptable (even desirable) that the implementation of these properties should not have a single locus, so that the system should display these properties without a single subsystem or system component being responsible for them. If awareness and coherency are emergent properties of the enterprise, it is likely that the enterprise (and its information system) would be more resilient in terms of being able to maintain these systemic properties.
It is clear that the future is not in EA reinventing the complete gamut of management models, but it is in providing a unifying platform through which the multiple models used in the various life cycle phases and in the various stages of the enterprise’s life history can be combined. The combination needs a new paradigm though, as current EA methodologies struggle with the reality of complex relationships among models present at different abstraction levels. In essence, guided evolution of the enterprise requires that enterprise modelling not be seen as a top-down or bottom up process, but as a powerful problem finding and problem solving tool that supports transformational activities both on the strategic and operational levels.
In my article from 2013, The Changing Role of the Enterprise Architect, I argue that in facing ‘wicked problems’, enterprise architects must focus more on problem-finding than problem-solving; true craftsmen look at situations in a problem-finding manner, rather than blindly applying the same method and tool every time to what may be a new and interesting challenge.
Enterprise architecture practice must be collaborative, and enterprise architects should be cooperative in character, able to engage in many kinds of communication and collaboration. I argue that enterprise architects must have both:
dialectic skills and competencies in resolving conflicts, creating consensus, synthesis and common understanding, detecting what might establish that common ground, and the skill of seeking the intent rather than just reading the face value of the words, and
dialogic skills including listening well, behaving tactfully, finding points of agreement, managing disagreement, and avoiding frustration in a difficult discussion.
Jason Uppal picks up on this in his lecture at a recent EA conference.
The dialectic/dialogic distinction is of course a classic discourse in educational research (see for example Rupert Wegerif, Richard Paul, and Andrew Ravenscroft) and generally throughout the critical social sciences (“Bakhtinian dialogic and Vygotsky’s dialectic”) ever since Hegel.
In Together: The Rituals, Pleasures, and Politics of Cooperation sociologist Richard Sennett states that the distinction between dialogic and dialectic is fundamental to understanding human communication. Sennett says that dialectic deals with the explicit meaning of statements, and tends to lead to closure and resolution. Whereas dialogic processes, especially those involved with regular spoken conversation, involve a type of listening that attends to the implicit intentions behind the speaker’s actual words. Unlike a dialectic process, dialogics often do not lead to closure and remain unresolved. Compared to dialectics, a dialogic exchange can be less competitive, and more suitable for facilitating cooperation. Sennett explains further in a lecture at Harvard: The Architecture of Cooperation.
The Importance of Enterprise Collaboration
Cooperation and collaboration are closely related concepts, and often thought of as synonymous. In fact, they are quite different.
Oscar Berg‘s Collaboration Pyramid may explain the difference:
Berg distinguishes between the three layers in this way:
The community is the enterprise seen as a group of individuals that share the same purpose, vision and values. It is about shared attitudes and behaviors within the enterprise, or the culture if you like. It is also about the individual’s ability to be seen, participate and be recognized, all of which are fundamental for developing a sense of belonging, identity, and self-confidence.
Cooperation is about people enabling each other to do something, for example by providing a person with information or other resources that make the person more able to perform a task. Cooperation can be seen as the opposite of selfishness and competition. People help each other out for some mutual benefit.
Collaboration is about a team of people that work closely together to achieve a certain goal. It can be a permanent team, like a production unit at an assembly line, or temporary team, like a project team. The team would most likely have a formally appointed leader, someone who is responsible for the planning, coordination, follow-up, and communication within the team as well as the world outside the team.
Enterprise collaboration is a term that covers all these three all-important concepts of the “social” enterprise. The term is often mistakenly used to cover social networking tools and intranet, but should be seen as a wider concept and a more comprehensive platform for the enterprise, wherefrom strategic alignment and viable process and information flows are tangible outcomes.
In our Collaboration whitepaper, we explain further how QualiWare is enabling our customers to work with collaboration in their enterprise architecture work.