Driving Enterprise Architecture (EA) With BPM - Part II
Since we have established the importance of BPM towards EA, it would now be appropriate to discuss how we would drive EA with BPM. If you recall from our previous article on “Why to drive EA with BPM”, the key differentiator between a conventional EA initiative and a BPM driven EA initiative is the fact that BPM driven EA initiatives to transform your EA initiative from being a static snapshot of your organizational framework to a transformative and informative live representation of the current architectural blueprint of your enterprise. That being said, how then would we go about establishing BPM that would allow us to drive an EA initiative in perpetuity.
At the initiation of a BPM driven EA initiative, it would be important to first define the standards, methods, and conventions for a process design. This means defining the types of models and objects that you would like to use when designing the process. This definition is not just limited to the tasks to be performed but also the support people (such as the RACI), inputs and outputs (in terms of data or information required), and technologies (such as systems and documents) in place. This is usually defined by the process analysts who are in charge of designing and analyzing the business processes for improvement potential.
It is important to note here that for BPM driven EA initiatives, the respective architects (Business, Data, and Application Architects) should also be involved in this standardization exercise as they would also need to determine the additional details or attributes that should be defined for each of their respective artefacts, such as contact information for persons, data details for data sets, application owners and support teams for various applications et. Cetera. The rule of thumb for what attributes to define for each artefact type is determined by the reports that the Architects would like to extract, with the exception of the relationships between different artefacts which would be defined by the logical sequence of tasks that incidentally also prescribes the manner of interaction between different artefacts. These standards, methods, and conventions establish a uniform and communalized language in which a process is being described and sets a checklist of all the artefacts that should be collected when defining how work should be performed.
Once this standard has been established, the process analysts would then start going about collating the required process flow and the respective details revolving around each task. This is the stage where the architects would also participate in the collation of their respective architectural artefacts (including the organizational objects, the data objects, and the system objects). Any information that is deemed missing would be gathered either directly from the stakeholders or any other reference points such as CMDBs (Configuration Management Databases). The main objective to note here is to ensure that the entirety of the architecture is derived from the business processes to ensure the most relevant and reflective logical state of utilization of all the artefacts and thereto the architectures.
With the derivative architectures being drawn up, Enterprise Architects will then need to conduct one final step to determine if the list of all available artefacts (i.e. the physical state of people, data, and systems) are in sync with the derived state (i.e. the logical state). This is where the all-important question of “Which resources are important?” is brought to light and answered. If there exists a gap between the logical and physical architectures, then it would be both the architects’ and the analysts’ jobs to mitigate the gaps, either by updating missing artefacts in the logical architecture and defining its utilization or by highlighting the physical artefacts as redundant or unused to be earmarked for sunset. Regardless, the final state of the derivative architectures must be in perfect synchronicity with the logical sequence of the business processes.
Once this synchronous architecture of both logical and physical designs is founded, reports can then be created to automatically determine the physical relationships between the various artefacts of the enterprise, be it between people and process or process and technology or people and technology, et cetera, by virtue that how people, process and technologies interact are all defined by the logical sequencing of their utilization from one task to another in the business process. Impact analysis for any changes required of any artefact can also be quickly collated across the entirety of the process architecture to determine the effects of the change. Most importantly, as process monitoring mechanisms can be easily put in place to continuously audit the process performances, we would also be able to derive live states of how the physical artefacts and thereto the architectures are performing. In essence, our derivative architectures would now be living reflections of how all artefacts prescribed by the business processes are behaving.
All in all, BPM driven EA initiatives target to harmonize the logical and physical designs of Enterprise Architectures albeit in a derivative manner, resulting in a methodology that establishes not just a consistent and standardized way of defining Enterprise Architectures but a sustainable and scalable technique for maintaining Enterprise Architectures as the organization evolves.
Podcast
Other Info-Hub
Driving Enterprise Architecture (EA) With BPM - Part II
27 June 2022
Driving Enterprise Architecture (EA) With BPM - Part I
3 June 2022
How To Achieve BPM
19 May 2022
Why Practise Business Process Management (BPM)
20 April 2022
Stick and Carrot
31 March 2022
Size Doesn’t Matter – BPX Does
24 March 2022
Business Process Excellence (BPX) - The New Driver To Work-Life Balance
27 Feb 2022
中文