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.
Featured Speakers:
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; susan@closereach.ca, 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!
Are you using Archimate 3.0 Specification as your modelling standard? Do your current tools enable you to work with this and other standards as easily as you would like?
If not, you may be interested to find an easy-to-use, repository-based tool to fully support your requirements. You can manage all your architecture needs, and:
Reduce errors in managing the complexity of ArchiMate 3.0
Reduce amount of documentation required through re-using your objects and models
Save time and reduce duplication of work
Add properties to your ArchiMate symbols
Speed up work by using non graphical relations
QualiWare Enterprise Architecture Suite fully supports the new Archimate 3.0 Specification. This includes:
Support for all constructs, relationships, and controls for ArchiMate 3.0
Ability to link your Archimate models to models for other standards
Support for all new 3.0 viewpoints
Drag and drop any of the 56 symbols into your diagrams
Join our Archimate 3.0 webinar
Monday the 26th September at 4pm CET (3pm UK)
Through this webinar you’ll get a brief Introduction to QualiWare and ArchiMate. We will look at what’s new in ArchiMate3.0. How to draw ArchiMate3.0 diagrams in QualiWare and how you can link ArchiMate with other diagrams and standards.
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
Categories of technical assets.
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:
Industrial cultures and their “movements”
RAMI 4.0 and IIRA are the two major deliverables from the two “movements”, Industrie 4.0 and the Industrial Internet. Representatives from these “movements” were brought together in a panel here the other day at the Hannover Messe, and a report, BAM! POW! Industrie 4.0 Meets the Industrial Internet!, notes that
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:
Comparison of Industrie 4.0 and the Industrial Internet Consortium. Source: MAPI Foundation
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.
Fast forward, and many frameworks and methodologies later, GERAMs authors did a recent review of the last 20 years with reference architectures, and observed,
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.
More than 10 billion Euros will be spent on 16 new hospital construction projects in Denmark. One of the larger projects, dubbed a “super-hospital,” is in Odense, where the budget is 1.3 billion Euros. The New Odense University Hospital (Nyt OUH) will be approximately 250.000 m2 and is scheduled to be ready in 2022. It will become the largest hospital in Denmark that is built from scratch.
Budget 1.3 €billion
Floor area 250.000 m2
New OUH is a green-field mega-project which will replace the existing university hospital (OUH). So on one hand, it is a rare opportunity to architect a digital enterprise “ground-up”, regardless of the existing built-environment, but on the other hand, it is also a significant transition challenge for the existing enterprise.
The overall vision for New OUH is:
A university hospital is a highly technological and knowledge intensive enterprise that depends on knowledge being shared and used optimally in the primary production – treatment of patients and research. Knowledge in the hospital must flow freely inside the networks and between the relevant operators and must be available at any time and in such a fashion that it can be utilized immediately.
The Digital Hospital is a composite term consisting of the word Hospital. This represents the core service – diagnosing and treatment of patients and thus the circuit of knowledge while the Digital is a supporting and developmental term to the core service. The Digital element in New OUH must be omnipresent and must ensure that New OUH can realize its vision and make full and optimal use of the knowledge circuit. In other words, the Digital hospital is a precondition for the knowledge circuit in New OUH.
Jonas Hedegaard Knudsen, CIO
Digital solutions at New OUH will be for all, to all, between all, everywhere – always.
For all
Digital solutions must support all users of the hospital and its functions. Concurrently, the digital solutions will help convert data into information to the benefit of the sharing of knowledge, treatment, care and research. The digital solutions must support exchange of information/communication as well between the different users, and deliver to such an extent that they support proper communication between the parties and in a fashion making it relevant for the information seeker. When the term “all” is used it refers to patients, next of kin, hospital employees, GPs, municipality and scientific researchers at the university.
To all
Digital solutions for all are regarded as any productive process at New OUH is digitally supported. Data, information and knowledge flow freely and automatically to all people as well as systems, thus supporting the hospital processes in the best possible way and at any time providing the employees with the necessary knowledge needed to perform their tasks. “To all” constitutes a movement from one operator to (“all”) another operator. This movement rep-resents knowledge shared transparently and automatically. Data, information and knowledge thus flow to and between all productive operators and processes at the hospital.
Between all
Digital solutions between all tie individuals, work processes and solutions together in a holistically orientated network2. In other words, we are talking about coherent sharing of information and knowledge between all operators in a network. “Between all” is thus regarding the coherence and integration of concepts. The digital elements is seen as coherence and integration on three levels: between individuals, between equipment, and between equipment and individuals. The digital hospital must contribute to information and knowledge being made available in such a way that it can be integrated and utilized between all operators and network in and around the hospital’s technical and productive processes.
Everywhere
Digital solutions “over all” mean that the solutions must be available and integrated for all, in and around the hospital, patients as well as external partners. This availability “everywhere” facilitates communication, sharing and creation of knowledge. Therefore “Everywhere” must not be viewed as a (narrow hospital based) concept but as including all partners (patients, scientific researchers, municipalities etc.) “Everywhere” covers, in other words, the geographical and organizational areas that participate in or around a specific productive process offered by the hospital to a patient or a group of patients. “Everywhere” thus facilitates both and organizational perspective, a process related perspective, and a geographical perspective. This means that digital solutions “everywhere” must be an organizational part of the entire hospi-tal, support all productive processes in such a way that these can be utilized in the best possible way regardless of geographical location.
Always
Digital solutions must always be present and support the user at any given time to be able to procure the requested information – regardless of place and time. This means that the digital solutions support availability of information for the user at the time the information is requested. This means that during an operation the surgeon can pull vital information that the researcher has unlimited access to quality data in his field. That data is available regardless if the user is present at the hospital, the university or outside.
New OUH has chosen QualiWare’s digital business design platform for the ongoing architecture and design work on the digital enterprise. QualiWare is already used at the existing OUH for asset management in several clinical areas.
The New OUH enterprise architecture team will over the next 6 years need to flesh out actionable digital business design, and realize the digital hospital vision. QualiWare Center of Excellence will support the EA team in these efforts.
In future blogs, we will offer more updates and elaborations on the digital hospital.
Many firms in the oil sector are struggling due to the steep drop in oil prices. Across the sector there has been a reduction in investment, and in many cases downsizing. Planning for the future in these times can be tough, and changes need to be made in order to survive. However, some firms are not only working on surviving but also putting themselves in a strong position to capitalise on opportunities when oil prices eventually rise and stabilise. Furthermore, these firms are also making big changes towards digitalisation, and modernising the way they do business in spite of the slump.
Oil & Energy firms, both upstream and downstream, are typically highly complex. Equipment, assets, process, systems, applications, broad webs of suppliers and customers, and a large and varied workforce are integral to keeping everything running at a profit. Regulatory requirements are not getting looser but tighter, this all adds the huge running costs which do not get lower as the oil price does.
However, there are opportunities to be exploited. The big question is how?
Align Business & IT
Oil & Energy enterprises will typically have thousands of applications, and the associated infrastructure to run and host these systems. Therefore you should start by creating a common enterprise model accurately showing how IT systems support business processes and identify the need for process information and data. From there, you can define the key applications for development and maintenance, and importantly, identify redundant and overlapping applications to be phased out. This allows the enterprise to focus investments in the right areas. Through this process, we’ve seen oil & energy enterprises save millions of dollars annually in support & maintenance costs. Furthermore, it will allow you to focus important resources on developing a modern, digital enterprise architecture.
Adapt to New Digital Technologies
The downturn has brought forth many new technologies designed to improve efficiency and reduce costs. And they have already started making an impact. Your firm will be looking into or already implementing new automation technologies, exploiting big data, or bringing in customer focused technologies such as multichannel marketing platforms. Capital projects will still be a large feature, and ensuring all these projects run on-time and on-budget is not simple.
In order to bring in these new technologies successfully, different stakeholders and cross-functional teams will need to see how the solution fits with the current organisation, the changes that need to be made, understand the impact of change to mitigate risks. Take your enterprise model and publish this to the web so everyone can see it. Ensure those involved in change can access all the information they need to facilitate the transformation, and provide a platform for all parties to collaborate.
Set up for Rapid Reaction to Market Change
If the oil market picks up in the next 12-18 months, you need to be in a position to react rapidly to changes. A well-defined company architecture, aligned to corporate goals will allow the organisation to react quickly when the time comes. This should include each employee having access to all the information they need to do their job, get trained, and understand how they fit into the wider context.
With the slump in oil prices continuing and no concrete timeline for when it will improve, can you afford to sit tight and hope for the best? Or is it time to visualise the changes you need to make, and work together to transform your business?
I’m looking forward to speaking about trends in enterprise architecture at the EA2015 conference on 4 November in Copenhagen. Having spoken at this annual conference over the past several years, it is my annual “state-of-the-union” address to the Danish EA community.
This year, I will talk about several trends and issues. The outline of the lecture looks like this:
The current state of #EntArch
So, is there a problem?
“The only thing that’s changed, is everything”
EA scholary analysis
EA scope creep
Gartnertology
We’re not in Kansas anymore
Enterprise Investment
Enterprise Design
Suggestions
You can get my slides here, but most of them are not very informative on their own.
Although I use different evidence, many of my points are also expressed in my crossroads blog post and article. But I will also bring up several other points. I’ve even invented a new word: Gartnertology. This I use to describe how Gartner is becoming something akin to a religious cult.
I will of course here refer to Kuno Brodersen’s recent blog post about Gartner’s tool assessment practice, but will focus more on Gartner’s recent messages about digital business, and discuss these. And then rather quickly move on to something more interesting, including enterprise investment and enterprise design.
All in all, a lot of content for a 45 minutes lecture. So participants will be told to fasten their seat-belts.
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 Challenges
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).
Responses
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:
Towards Solutions
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.
More and more QualiWare users consider a consensus-driven management philosophy and enterprise collaboration to be a key driver for business agility and innovation. This has always been essential for QualiWare when we design our products and services.
For several years, we have been surprised and disappointed that Gartner sticks to a rather traditional view on EA Tools, when they evaluate a vendor. For us, collaboration is such a central prerequisite for an enabling and outcome-driven enterprise design platform. For Gartner, collaboration is hardly mentioned in the criteria for evaluation and is completely lacking in several important areas.
QualiWare delivers a platform for Enterprise Architecture Management and several other management systems. For us, and for all of our customers, the collaboration features are core functions in the implemented information system. Further details on this can be found in our whitepaper Collaboration: The Key to Successful Enterprise Architecture.
Gartner’s evaluation criteria are not available in the public domain, so we cannot go into details in this blog. But suffice to say that Gartner ranks stuff like “print hardcopy” higher than the total sum of collaboration features in an EA tool.
It is particularly striking that the evaluation criteria neglect collaboration when Gartner in much of their research over the past five years have – like other analysts – argued that collaboration is key to the success of enterprise architecture. Perhaps the “magic” in the Magic Quadrant is a five-year delay? It certainly seems so.
Over the past year, QualiWare has doubled the number of users on our collaboration platform, which now has hundreds of thousands of users across enterprises around the globe. See our whitepaper for more evidence and customer examples.
The shift in EA towards collaboration is a response to several challenges. EA is at a crossroads, and should be regarded as a powerful problem finding and problem solving tool that supports transformational activities both on the strategic and operational levels. Read John Gøtze’s blog post about this.
QualiWare strongly recommends Gartner to include collaboration relevant criteria in future EA tool evaluations. We also encourage Gartner to make their evaluation criteria public and accessible to all, and engage in a public dialogue about these. QualiWare is very keen on engaging in such open dialogues, and open all our social platforms for that purpose: Make comments to this blog, or on our Linkedin page, to our Twitter handle, or on Facebook.
The European Interoperability Reference Architecture (EIRA) is
an architecture content metamodel defining the most salient architectural building blocks (ABBs) needed to build interoperable e-Government systems.
On 8 June 2015, release 0.9.0 beta of the EIRA entered an eight-week public review period. Stakeholders working for public administrations in the field of architecture and interoperability were invited to provide feedback.
The EIRA is a four-view reference architecture for delivering interoperable digital public services across borders and sectors. It defines the required capabilities for promoting interoperability as a set of architecture building blocks (ABBs). The EIRA has four main characteristics:
Common terminology to achieve a minimum level of coordination: It provides a set of well-defined ABBs that provide a minimal common understanding of the most important building blocks needed to build interoperable public services.
Reference architecture for delivering digital public services: It offers a framework to categorise (re)usable solution building blocks (SBBs) of an e-Government solution. It allows portfolio managers to rationalise, manage and document their portfolio of solutions.
Technology- and product-neutral and a service-oriented architecture (SOA) style: The EIRA adopts a service-oriented architecture style and promotes ArchiMate as a modelling notation. In fact, the EIRA ABBs can be seen as an extension of the model concepts in ArchiMate.
Alignment with EIF and TOGAF: The EIRA is aligned with the European Interoperability Framework (EIF) and complies with the context given in the European Interoperability Strategy (EIS) . The views of the EIRA correspond to the interoperability levels in the EIF: legal, organisational, semantic and technical interoperability. Within TOGAF and the Enterprise Architecture Continuum, EIRA focuses on the architecture continuum. It re-uses terminology and paradigms from TOGAF such as architecture patterns, building blocks and views.
EIRA in one picture
The figure below provides a high-level overview of the four views in EIRA. Each of the four views consists of a set of Architecture Building Blocks (ABBs) and relations pertaining to the legal, organisational, semantic and technical domain of an Interoperable European Architecture. Each view has entry and exit points from one view to another.
The legal, organisational, semantic and technical domains are the classic European interoperability concerns. The EIRA defines building blocks for each view.
In addition, a new Interoperability specification underpinning view has been added as an additional view, depicting architecture building blocks of the different views as a taxonomy of interoperability specifications:
The “metaview” detailing and specifying interoperability.
EIRAs raison d’etre?
The key concepts of the EIRA and their relationships are described here:
The following list explains the different relationships:
A. The EIRA is derived from the European Interoperability Framework (EIF);
B. The EIRA has one view for each EIF interoperability level;
C. Each EIRA view contains several EIRA ABBs;
D. EIRA ABBs can be used to create reference architectures;
E. A SAT addresses a certain interoperability need. It consists of a sub-set of the most important EIRA ABBs and is derived from a reference architecture;
F. An EIRA SBB realizes one or more EIRA ABB;
G. A (interoperable) solution consists of one or more SBBs;
H. A (interoperable) solution realizes a solution architecture;
I. A solution architecture can be derived from a SAT or directly from a reference architecture;
J. As the EIRA focuses only on the most important ABBs needed for interoperability, other ABBs (= non-EIRA ABBs) can exist;
K. Similar to ABBs, non-EIRA SBBs can exist next to EIRA SBBs.
Release 0.9 of the EIRA does not provide as much detail about the SBBs as it does on the ABBs. This will be done in another project. Also see the SBB template document.
Further information about the EIRA can be obtained in the document ‘An introduction to the European Interoperability Reference Architecture v0.9.0’ (EIRA_v0.9.0_beta_overview.pdf). The release consists of the following release components:
EIRA_v0.9.0_beta_overview.pdf:PDF document containing an introduction to the EIRA, including its key concepts, used ArchiMate notation, tool support, and views.
EIRA_v0.9.0_beta_ABBs: An HTML file containing the definitions of the architecture building blocks.
EIRA lists 161 architecture building blocks. Of these, more than half are technical:
82 Technical View (27 Application and 55 Infrastructure)
26 Organisational View
19 Semantic View
18 Legal View
6 Interoperability View
10 Deprecated (11 if ABB59 Logging Service included – not marked in View:Deprecated but in Status).
The building blocks are described via selected archimate model concepts, of which four are used a lot:
40 archimate:ApplicationService
34 archimate:BusinessObject
26 archimate:ApplicationComponent
18 archimate:DataObject
Other model concepts are also used:
6 archimate:BusinessProcess
5 archimate:Contract
4 archimate:BusinessActor
3 archimate:BusinessRole
3 archimate:InfrastructureService
3 archimate:Network
3 archimate:Node
2 archimate:ApplicationInterface
1 archimate:BusinessFunction
1 archimate:BusinessInteraction
1 archimate:BusinessInterface
1 archimate:BusinessService
So, looking at the big picture, EIRA is perhaps a bit “heavy” on the technology side of interoperability, but does cover the four layers. In particular, EIRA establishes a set of views across the four layers. In doing so, it has to “embrace and extend” ArchiMate.
EIRA and ArchiMate
EIRAs commitment to ArchiMate is somewhat courageous. And somewhat creative, for example:
EIRAs Business Capability is covered by archimate:BusinessFunction
EIRAs Business Information Exchange is covered by archimate:BusinessInteraction
A Business Capability is the expression or the articulation of the capacity, materials and expertise an organization needs in order to perform core functions. Enterprise architects use business capabilities to illustrate the over-arching needs of the business in order to better strategize IT solutions that meet those business needs.
A Business Information Exchange is a piece of business data or a group of pieces of business data with a unique business semantics definition in a specific business context [ISO15000-5, UN/CEFACT CCTS].
These are work-arounds to two well-known ArchiMate limitations.
The archimate:BusinessObject is also quite busy, and for example covers these ABBs:
Business Rule
Business Information
Organisational Procedure
Organisational Structure
Again, work-arounds to current ArchiMate limitations.
EIRAs ABBs have changed with each release. Deprecated ABBs in the 0.9 beta include:
Business Process
Business Process Model
Business Transaction
Licensing and Charging Policy
Privacy Policy
Metadata Management Policy
Data Routing Service
Data Routing Component
Information Security Policy
Data Quality Policy
Logging Service?
So, Business Process and Business Process Model are deprecated, but the archimate:BusinessProcess model concept is used several times, namely for these ABBs:
Public Policy Cycle
Definition of Public Policy Objectives
Formulation of Public Policy Scenarios
Impact Assessment
Public Policy Implementation
Public Policy Evaluation
ArchiMate of course allows for a certain amount of flexibility (ArchiMate 2.1, Chapter 9 Language Extension Mechanisms), but the creativity can be dangerous, expecially in an interoperability context.
EIRA is an many ways ahead of ArchiMate. The challenge is that ArchiMate is under continuous development, and is likely to change on exactly these areas in future versions (see chapter 12.1 in the ArchiMate 2.1 spec). So EIRAs current notation standard should be seen as a temporary “fix”.
A note of caution
EIRA has obviously selected a winner of the longstanding Process vs Capability Debate. Eradicating processes is rather bold, and contrary to advice from experts like Roger Burlton, Paul Harmon, Alan Ramias and Andrew Spanyi, and Keith Swenson. While it is laudable to focus on capabilities, the use of capabilities should not be seen as an alternative to using processes and business process models. Both are needed.
From a maturity standpoint, this is only just acceptable. Even an Excel sheet version would be better, but better would be “raw data” available in a range of formats, possible as an api.
EIRA does not have any mapping to any other framework.
The Legal and the Organisational views are less conventional as architecture views go. The Semantic, Application (Technical) amd Infrastructure (Technical) views are classic architecture views in many EA frameworks. A comparison with established frameworks seems to be a good idea.
A key part of the US Federal Enterprise Architecture Framework Version 2 (FEAF-II) is the Consolidated Reference Model, which equips the US Federal Government and its Federal agencies with a common language and framework to describe and analyze investments. It consists of a set of interrelated reference models that describe the six sub-architecture domains in the framework:
Strategy
Business
Data
Applications
Infrastructure
Security
EIRAs Legal view is roughly equivalent to FEAF-IIs Strategy (Performance Reference Model), and EIRAs Organisational view roughly equivalent to FEAF-IIs Business Reference Model.
Contentwise, EIRA and FEAF-II use these two layers in different ways:
US FEAF-II Performance Reference ModelEU EIRA Legal Interoperability viewEIRAs organisational viewUS FEAF-II Business Reference Model
EIRAs model scope is wider than FEAF-IIs, but FEAF-II is more comprehensive as a classification scheme.
EIRA should consider taking inspiration from FEAF-II, and at least add a security view. If anything, such view should become mandatory for all European governments.
Towards EIRA 1.0
The 0.9 release of EIRA is a big step forward for reference architecture work in European governments.
QualiWare proposes a rapid consolidation and documentation process, and then releasing Version 1.0. EIRA should not await the next version of ArchiMate, but rather run with well-documented revision control.
QualiWare is committed to supporting international governments in their interoperability work. QualiWare fully supports using ArchiMate 2.1. If customer demand requires it, the “EIRA ArchiMate” approach can easily be supported.
RAMI 4.0 
