Aggregated enterprise architecture wisdom
In the various previous posts about EA metamodels, we’ve been exploring some of the detailed structures for toolsets and the like at a very, very low-level. But what’s the big-picture here? What’s the point? So let’s step back for a moment, and look at real-world EA practice. Much of our work consists of conversations with […]
What would this ‘generic modelling metamodel’ look like? And how could we implement it? This continues the work from previous posts on this theme, such as ‘More detail on EA metamodel‘ and ‘EA metamodel and method‘. The legal bit: The aim is that this should contribute towards an open standard, and should not be used […]
How would this EA metamodel actually work? And why would we need it, given that we have more than enough frameworks and models already? This follows on from the earlier post ‘More detail on EA metamodel‘, and in particular part of a comment there from Stuart Boardman: I completely agree that method and governance should […]
My earlier post ‘IT-centrism is killing enterprise-architecture‘ seemed to touch a nerve with quite a few folks: tetradian: [post] IT-centrism is killing enterprise-architecture http://bit.ly/p8kfqf (thx @dougnewdick) #entarch tonia_ries: The only thing that should be at the center of any business is the customer. @krcraft @tetradian krcraft: Agree, if staff also inc. as customers RT @tonia_ries […]
Whenever I suggest collaboration between these two worlds, I always observe some sort of astonishment from my interlocutors. Many Enterprise Architects or Business Architects do not realise there may be synergies. Business Process Management (BPM) team have not understood what Enterprise Architecture is all about and the other way around…. There is no a single definition of Business Process Management, often it means different things to different people. To keep it very generic, BPM relates to any activities an organization does to support its process efforts.
There are many activities which can be included in such efforts:
· The use of industry Business Reference Model (or Business Process Reference Model), a reference for the operational activities of an organization, a framework facilitating a functional Lines of Business, such as
o The Federal Enterprise Architecture Business Reference Model of the US Federal Government
o The DoD Business Reference Model
o The Open Group Exploration and Mining Business Reference Model (https://www.opengroup.org/emmmv/uploads/40/22706/Getting_started_with_the_EM_Business_Model_v_01.00.pdf)
o Frameworx (eTOM) for Telco companies
o The Supply Chain Operations Reference (SCOR®) model
o The SAP R/3 Reference Model
o The Oracle Business Models : Oracle Industry Reference Model for Banking, (IRM), Oracle Retail Reference Model
o And others…
· The use of organization specific Business Reference models
· The use of Business process improvement methodologies
o Lean, a quantitative data driven methodology based on statistics, process understanding and process control
o Six Sigma, a methodology that mainly focuses on eliminating bad products or services to clients by using statistical evaluation
· Business Process Reengineering, which in reality is a facet of BPM
· The understanding of Business Change Management, the process that empowers staff to accept changes that will improve performance and productivity
· The understanding of Business Transformation, the continuous process, essential to any organization in implementing its business strategy and achieving its vision
· The use of Business Rules Management which enables organizations to manage business rules for decision automation
· The understanding of Business Process Outsourcing (BPO) services to reduce costs and increase efficiency
· The support of Business Process modeling and design, which is illustrated description of business processes, usually created with flow diagrams. The model contains the relationship between activities, processes, sub-processes and information, as well as roles, the organization and resources. This can done with many notations such as flow chart, functional flow block diagram, control flow diagram, Gantt chart, PERT diagram, IDEF, and nowadays with the standard de facto notations such as UML and BPMN
· The support of BPM tools and suites implementation. With the right, process models can be simulated, to drive workflow or BPMS systems, and can be used as the basis for an automated process monitoring system (BAM)
· The support of Business Activity Monitoring (BAM), the ability to have end-to-end visibility and control over all parts of a process or transaction that spans multiple applications and people in one or even more companies.
To combine Business Process Management and Enterprise Architecture for better business outcomes is definitely the way forward, where BPM provides the business context, understanding, and- metrics, and Enterprise Architecture provides the discipline to translate business vision and strategy into architectural changes. Both are needed for sustainable continuous improvement. When referring to Enterprise Architecture, we would mainly refer to Business Architecture. Business Architecture involves more than just the structure of business processes. It also entails the organization of departments, roles, documents, assets, and all other process-related information.
Business Architects may be defining and implementing the Business Process framework and, in parallel, influencing the strategic direction for Business Process Management and improvement methodologies (e.g. Lean, Six Sigma). The business process owners and Business Analysts are working within their guidelines at multiple levels throughout the organizations’ business process. They have roles and responsibilities to manage, monitor and control their processes.
An important tool in developing Business Architecture is a Business Reference Model. These types of models are enormously beneficial. They can be developed in the organization to build and extend the information architecture. The shared vocabulary (verbal and visual) that emerges from these efforts promotes clear and effective communication.
To illustrate the touch points between Enterprise Architecture and Business Process Management, I have illustrated in the table below the synergies between the two approaches using TOGAF® 9.
In this table, we observe that, there is a perfect match between Business Process Management and the use of an Enterprise Architecture framework such as TOGAF. BPM is often project based and the Business Architect (or Enterprise Architect) may be responsible for identifying cross-project and cross-process capabilities. It can be considered as being the backbone of an Enterprise Architecture program. We can also add to this, that Service Oriented Architecture is the core operational or transactional capability while BPM does the coordination and integration into business processes.
When using BPM tools and suites, you should also consider the following functionalities: workflow, enterprise application integration, content management and business activity monitoring. These four components are traditionally provided by vendors as separate applications which are merged through BPM into a single application with high levels of integration. The implementation of a BPM solution should theoretically eliminate the maintenance and support cost of these four applications resulting in reducing the total cost of ownership.
Business Architecture provides the governance, alignment and transformational context for BPM across business units and silos. Enterprise Architects, Business Architects, Business Analysts should work together with BPM teams, when approaching the topic of Business Process Management. BPM efforts need structures and appropriate methodologies. It needs a structure to guide efforts at different levels of abstraction (separating “the what“ (the hierarchical structure of business functions) from “the how” (how the desired results are achieved), a documented approach and structure to navigate among the business processes of the organization, i.e. a Business Architecture. They also need a methodology such as an Enterprise Architecture framework to retain and leverage what they have learned about managing and conducting BPM projects.
Whenever I suggest collaboration between these two worlds, I always observe some sort of astonishment from my interlocutors. Many Enterprise Architects or Business Architects do not realise there may be synergies. Business Process Management (BPM) team have not understood what Enterprise Architecture is all about and the other way around…. There is no a single definition of Business Process Management, often it means different things to different people. To keep it very generic, BPM relates to any activities an organization does to support its process efforts.
There are many activities which can be included in such efforts:
· The use of industry Business Reference Model (or Business Process Reference Model), a reference for the operational activities of an organization, a framework facilitating a functional Lines of Business, such as
o The Federal Enterprise Architecture Business Reference Model of the US Federal Government
o The DoD Business Reference Model
o The Open Group Exploration and Mining Business Reference Model (https://www.opengroup.org/emmmv/uploads/40/22706/Getting_started_with_the_EM_Business_Model_v_01.00.pdf)
o Frameworx (eTOM) for Telco companies
o The Supply Chain Operations Reference (SCOR®) model
o The SAP R/3 Reference Model
o The Oracle Business Models : Oracle Industry Reference Model for Banking, (IRM), Oracle Retail Reference Model
o And others…
· The use of organization specific Business Reference models
· The use of Business process improvement methodologies
o Lean, a quantitative data driven methodology based on statistics, process understanding and process control
o Six Sigma, a methodology that mainly focuses on eliminating bad products or services to clients by using statistical evaluation
· Business Process Reengineering, which in reality is a facet of BPM
· The understanding of Business Change Management, the process that empowers staff to accept changes that will improve performance and productivity
· The understanding of Business Transformation, the continuous process, essential to any organization in implementing its business strategy and achieving its vision
· The use of Business Rules Management which enables organizations to manage business rules for decision automation
· The understanding of Business Process Outsourcing (BPO) services to reduce costs and increase efficiency
· The support of Business Process modeling and design, which is illustrated description of business processes, usually created with flow diagrams. The model contains the relationship between activities, processes, sub-processes and information, as well as roles, the organization and resources. This can done with many notations such as flow chart, functional flow block diagram, control flow diagram, Gantt chart, PERT diagram, IDEF, and nowadays with the standard de facto notations such as UML and BPMN
· The support of BPM tools and suites implementation. With the right, process models can be simulated, to drive workflow or BPMS systems, and can be used as the basis for an automated process monitoring system (BAM)
· The support of Business Activity Monitoring (BAM), the ability to have end-to-end visibility and control over all parts of a process or transaction that spans multiple applications and people in one or even more companies.
To combine Business Process Management and Enterprise Architecture for better business outcomes is definitely the way forward, where BPM provides the business context, understanding, and- metrics, and Enterprise Architecture provides the discipline to translate business vision and strategy into architectural changes. Both are needed for sustainable continuous improvement. When referring to Enterprise Architecture, we would mainly refer to Business Architecture. Business Architecture involves more than just the structure of business processes. It also entails the organization of departments, roles, documents, assets, and all other process-related information.
Business Architects may be defining and implementing the Business Process framework and, in parallel, influencing the strategic direction for Business Process Management and improvement methodologies (e.g. Lean, Six Sigma). The business process owners and Business Analysts are working within their guidelines at multiple levels throughout the organizations’ business process. They have roles and responsibilities to manage, monitor and control their processes.
An important tool in developing Business Architecture is a Business Reference Model. These types of models are enormously beneficial. They can be developed in the organization to build and extend the information architecture. The shared vocabulary (verbal and visual) that emerges from these efforts promotes clear and effective communication.
To illustrate the touch points between Enterprise Architecture and Business Process Management, I have illustrated in the table below the synergies between the two approaches using TOGAF® 9.
In this table, we observe that, there is a perfect match between Business Process Management and the use of an Enterprise Architecture framework such as TOGAF. BPM is often project based and the Business Architect (or Enterprise Architect) may be responsible for identifying cross-project and cross-process capabilities. It can be considered as being the backbone of an Enterprise Architecture program. We can also add to this, that Service Oriented Architecture is the core operational or transactional capability while BPM does the coordination and integration into business processes.
When using BPM tools and suites, you should also consider the following functionalities: workflow, enterprise application integration, content management and business activity monitoring. These four components are traditionally provided by vendors as separate applications which are merged through BPM into a single application with high levels of integration. The implementation of a BPM solution should theoretically eliminate the maintenance and support cost of these four applications resulting in reducing the total cost of ownership.
Business Architecture provides the governance, alignment and transformational context for BPM across business units and silos. Enterprise Architects, Business Architects, Business Analysts should work together with BPM teams, when approaching the topic of Business Process Management. BPM efforts need structures and appropriate methodologies. It needs a structure to guide efforts at different levels of abstraction (separating “the what“ (the hierarchical structure of business functions) from “the how” (how the desired results are achieved), a documented approach and structure to navigate among the business processes of the organization, i.e. a Business Architecture. They also need a methodology such as an Enterprise Architecture framework to retain and leverage what they have learned about managing and conducting BPM projects.
A picture may be worth a thousand words. But business leaders won’t hear anything an EA model has to tell them unless it’s in a form they can understand and find value with. That’s why the architecture team at USAA is using circular E…
A picture may be worth a thousand words. But business leaders won’t hear anything an EA model has to tell them unless it’s in a form they can understand and find value with. That’s why the architecture team at USAA is using circular E…
I have been working with several different perspectives on governance, strategy, it architecture and enterprise architecture. I have read several books on the three topics and as such I have been able to build a model for categorizing the literature. … Continue reading →
What do enterprise-architects do?
At first glance it’s not an easy question. We talk a lot, with many different people, about lots of different things; but we don’t seem to do much. We tend to use a jawbreaking jargon, about narratives of knowledge, terminology, taxonomy, and things with a 2.0 in the name; we mumble about […]
To ensure your EA initiative delivers business value, focus on the needs of the business community from analysts to middle managers to senior leaders. Present the information using visualizations they find useful, rather than trying to teach the…
To ensure your EA initiative delivers business value, focus on the needs of the business community from analysts to middle managers to senior leaders. Present the information using visualizations they find useful, rather than trying to teach them EA models. Let business users describe architecture components using terms they are comfortable with, and make sure you can quickly deliver finished architectures when users demand them.
Those are the lessons USAA’s architecture team has learned in its five year push to move EA from an IT-centered function to a vital solution for business planning and strategy at the financial services giant. As USAA has grown to 23,000 employees and 8.2 million members, the rate and magnitude of change has resulted in a level of complexity that requires a single cross-discipline, cross-organization architecture team.
In a June 15 Webinar for Troux, Michael Pemberton, Enterprise Architect in Transformation and Integration, suggested that EA and Business Technology Management practitioners focus on the following areas:
Find Your Proper Place in the Organization: Instead of an “Information Architecture Steering Committee” or a “Business Architecture Steering Committee”, USAA established a “Unified Architecture Steering Committee” that represents business architecture, information architecture, process architecture, IT architecture, change management, and organizational design.
To closely align Business Architecture with both business strategy and IT partners, the architecture team is part of the Transformation and Integration group, which along with the Strategy team is part of the Enterprise Strategy and Planning organization reporting to the CEO. IT Architecture lives within the CTO organization, reporting to the chief administrative officer who also reports to the CEO. While EA and IT do not report to the same organization, they work closely together daily – a key success factor.
Think Through Your Model: Correctly “architecting the architecture” improves the accuracy and maintainability of the models over time. Pemberton recommends, for example, using one model only for processes, another only for data, and another only for information. That way, he says, each model “will be simple as it can be, with the simplest mappings” but represent the complexity of the organization through “the relationships among the elements of each model.” He also recommends using a metamodel, like Troux’s that limits flexibility within each model, but allows flexibility among models. “That forces you to have better architectural practices,” he says.
USAA is using Troux to build a common repository and metamodel designed to unify the architects into a single, cohesive community.
Visualizations: Pemberton jokes about the pain the architecture team experienced trying to teach business managers to use EA models, rather than “enlightening” them with well-done visualizations that answer their critical business questions. After being told in no uncertain terms they weren’t useful, he says, the architecture team will “never again show one of our primitive models to the business. Our visualizations must be highly graphical, and show things like context, rather than content, and convey understanding and meaning, rather than information.”
Let the Business Use Its Own Vocabulary: The architecture team has very rigorous rules for naming functions with its models, but allows business executives to use more familiar names for functions within visualizations. “We maintain aliases to our strict definitions, but let the business use the terms with which it’s comfortable.” That way, business users get the answers they need, while the architecture team can enforce the rules that assure consistency and accuracy over time. Similarly, “If we are presenting a methodology to the business and use the word ‘architecture’ eyes glaze over,” he says. “We’ve learned to use the phrase ‘business design’ and business users respond ‘Ah ha! You are helping me design my business.’”
Build Your Capacity: Watch out for what Pemberton calls “killer demand curves” where business users suddenly demand lots of full architectures – immediately. “If you don’t have an EA practice that’s built to scale up to deliver quickly on demand, the business becomes disenchanted and sees you as an ivory tower, and what you do as vaporware.” Rather than deliver only visualizations, USAA’s architecture team is creating other deliverables such as a “Unified Business Design Playbook” that documents common methods for aligning deliverables across the organization. That’s among the ways it is attempting to scale the architecture by turning it into a multi-disciplinary, collaborative team sport.
As USAA’s EA/BTM practice continues to progress, he says, “the biggest benefit will be through the delivery of better business outcomes, through the reduction of redundancy and risks and sharing costs”.
It’s a far cry from being seen as an ivory tower exercise – and the key has been focusing on the needs of business users at all levels and delivering architectures in a form they can use.
To watch a replay of Michael Pemberton’s webinar, click here
