Post 1 – Help! We Don’t Have A Formal Business Architecture
I can’t remember a week that has passed in which some organization or another was forced to reduce payroll expenditures. As a long-time employee of a very large organization I have seen this play out more times than I can count. In my experience is plays out like this: 1) The decision to make payroll reductions is made by C-level executives, who then provide guidance to middle managers on the distribution of these cuts across organizational divisions and departments. These decisions are often subjective, and based on the knowledge, experience and gut-feelings of those with P&L responsibilities. 2) After a round of cuts, there is generally a scramble to figure out how to distribute the tasks of those cut among the survivors. It’s is generally a messy process and often times the gaps in business process coverage aren’t discovered until the last moment, forcing a crisis or near-crisis event. 3) Once the dust settles the staff is leaner, and in the short-term the organization’s balance sheet improves. However, there there is business process spaghettification. People end up taking on tasks that fall outside of their expertise and/or become overburdened and work less efficiently.
Notice that there is no mention of anyone consulting the Enterprise Business Architecture (EBA). Some organizations have no formal EBA, and therefore make decisions informed by experience and best-intentions. In some cases it works out, but in almost every instance such a scenario would be improved in consultation with the EBA. Gartner’s definition of EBA is as follows (Burton, 2008):
“That part of the enterprise architecture process that describes — through a set of requirements, principles and models — the future state, current state and guidance necessary to flexibly evolve and optimize business dimensions (people, process, financial resources and organization) to achieve effective enterprise change.”
EBA is a tool for understanding the business, business processes, and the relationships between people, departments and the technology that bind them. For mid-to-large sized organizations, it’s a critical tool for assuring that business decisions are carefully vetted and that far-reaching implications are understood. Having studied the models of business processes and the networks of information flow and relationships between all of the various EBA artifacts, informed decisions can be made. Agile organizations would be well-served to work with their Enterprise Architects to begin the process of building an Enterprise Business Architecture to inform on business decisions and to serve as a means of understanding current business current and future states.
EBA can be considered as a “channel for engagement” with the business (Burton, 2009). In other words, it’s a great segue-way for Enterprise Architects to engage the business on a topic in which the business will have a great deal of interest. If the business is lacking a formal business architecture, then it would be no surprise to me that the business would be eager to meaningfully engage on this topic and become a motivated participant in EBA codification.
Burton, Betsy. (2008). Understand Enterprise Business Architecture to Realize your Future State. Gartner. ID: G00158306
Burton, Betsy. (2009). Use EBA to Effectively Manage Business
Transformation, Turmoil and Evolution. Gartner. ID: G00165663
Post 2 – Is Our Organization Ready for Enterprise Business Architecture?
I’m not beyond doing a bit of lobbying to realize my goal of becoming a practicing Enterprise Architect. I found an opening in my organization’s recent reorganization effort, which entailed breaking down the old functional divisions and matrixing them together to provide integrated services. Another element of this reorganization effort is to streamline business processes across the organization. The organization has announced the creation of a Transformation Management Office, and also re-established an Enterprise Architecture team. Thankfully, my politicking hasn’t gone unnoticed (nor have the exorbitant bills for my grad school tuition). I was recently promised that I would have a role in this business process re-engineering effort – possibly as the second member of the EA group. However, getting what I’ve asked for may come bundled with a great many headaches. As I reflect on what this effort may entail, I have to wonder if the organization is ready for it. What will this effort entail and do we have the resources to dedicate to doing the job right?
Organizations aren’t born ready for Enterprise Business Architecture (EBA). There are a number of prerequisites for determining whether an effort to implement EBA is likely to succeed: availability of information, processes and skills (DeGennaro & Miers, 2012). All of these are challenges for my organization. Availability of information is a concern only in that, as an organization that grows through acquisition, there are a great many information silos to sort through to access all of the information needed to fully understand the business information flows. A second challenge is that the organization has no formal business architecture. A key executive told me during an interview for another course that others in the organization “probably don’t know what Business Architecture is”. This speaks not only to the lack of codified business processes, but also indicates the significant training needs that will be required to implement a standardized business process across the organization.
One specific challenge to address is that the organization lacks true business analysts – the employees in these roles are more akin to software systems experts that help the business to train employees in the use of software, provision new users, and prepare requirements documentation for new projects. However, since they are not embedded in the business these business analysts do not contribute meaningfully to whatever business architecture may exist, nor do they advocate on behalf of the business. Any architects assigned to work on business architecture development will be well served to take care not to be morphed into business architects or business relationship managers by virtue of their efforts (DeGennaro & Miers, 2012).
However, the organization also sports a number of very positive attributes that will ease the business process re-engineering process. For one, the organization has a well-defined strategy thanks to its collaboration with a well known management consulting firm. Moreover, the organization’s top executives appear to be genuinely supportive of the effort as indicated by regular emails coming from the C-Suite executives outlining the planned activities and future plans.
So, on one hand we have some technical, people and process challenges; On the other we have a dedicated executive team. How does this bode for the organization’s likelihood of successfully implementing business architecture? I suspect that, so long as the executive support does not waiver as the complaints from middle-managers start pouring in, the project will success. The dedication of management, I believe, will inspire others downstream to follow. Management must effectively the benefits of establishing/codifying the organization’s Business Architecture and how it will pay dividends in various other areas of the overall reorganization effort. Part of the organization’s goal entails moving to a more mature operating model, which will be eased through this Business Architecture effort. Other elements that would be more informed and efficiently implemented include leveraging SaaS, Big Data projects and even upcoming IoT efforts – all of which will be eased with the knowledge gained through a codified Business Architecture.
DeGennaro, T. & Miers, D. (2012). Assessing Organizational Readiness for a Business Architecture Program. Forrester Database.
Post 3 – My First Experience in Business Architecture Modeling
The image to the right represents my very first effort at business process modeling with Aris Express using BPMN. I now consider it to be crude compared to some of my latest modelling efforts, but I’m proud of it nonetheless because it represents my first real experience in attempting to understand a business process and model it and the underlying technical architecture. I learned a great deal in this exercise and I’d like to provide a summary of my experiences in order to generally inform as to what this process might look like for others endeavouring to do the same.
First – a warning. This is no trivial process! Initially I expected to sit down and complete this exercise in an afternoon. Ultimately it took me a couple of weeks to compile a list of all of the people, tools and business process steps required to create a business work product. I scheduled countless meetings with various individuals who carry out the modeled tasks – many of whom treated me with suspicion, indifference, or flat-out avoided me. Some of the people that I interviewed knew very little about the overall business process and preferred to stay within the safety of their sub-domain. Those few who had holistic knowledge of the process were particularly difficult to track down. In order to illicit cooperation I reviewed the help-desk queue and found that some key participants had outstanding technical issues – which I happily worked to resolve – and then, BAM!, I hit them with my questions.
My first interview was with a quite-willing participant. My organization’s EA group is a team of one (1). He was thrilled that I might be willing to offer up unsolicited (and unpaid) business process modeling in the area of “Customer Lifecycle Management”, which spanned all business contact points with the customer. I was asked to take on the subset of tasks related to the process of creating sales proposals through account setup. I was provided with a high-level summary of the groups and technologies involved in this process. Using it, and years of organizational knowledge, I embarked upon setting up interviews with individuals in the marketing, sales and ERP subject matter experts.
As previously mentioned, I went through some trials and tribulations to acquire the information I needed to model the current state of the process. In the end I was able to collect all of the information that I needed in order to model the current state model. However, as I embarked to actually create the model I realized that there were serious discrepancies between what had been described to me at a high level by the Enterprise Architect and what was described by the SME’s. I discovered that there were different tool sets being used for the same process. I also discovered that none of these tools had been integrated, and so there were distinctly different processes in place across the organization. Additional interviews revealed that some of these tools had been adopted by shadow IT efforts and were not available to those across the organization. IT was only made aware of these tools thanks to my final report and recommended future-state model.
To create my model I used Aris Express to create BMPM models of the entire process. I had an overarching process (depicted above), and then I created a number of sub-models that articulated the individual business steps by each actor. I had three distinct current state models – one each for each of the sets of tools being used to take customers through the first contact, proposal generation and account setup processes. My magnum opus was a future state that incorporated the “best of” and most economically and functionally-normative tools in use, as well as a plan for integrating each of the technologies.
In my enthusiasm for the project I had dared to hope that the outputs of my effort would have been utilized (or at least reviewed) by others within the organization. Unfortunately, I was informed that I had created some nice models, but that my suggested future state had already been independently discovered by the PMO, and that others were working on a comparable solution. Oh well, at least I had validation that I was on the right track!