==============================================================================

(Business) Context is Everything [6.1]

 

When the introduction to this week’s topic started off by noting that the business architecture layer is the least mature of those within the EA discipline, I was slightly bemused. And also amused. It’s like that advert on the side of the webpage was saying just what I was wanting to hear. You are reading my mind, sir! Truth in advertising? Let’s see.

First, unlike many of the subjects we’ve covered, this is one of the areas I’m less familiar with, so the level of insight I can offer may be below average. Hey, your get what you pay for. Therefore, I’ll stick to a brief summary and comparison of a couple of the aspects that I thought were most relevant to me and how they relate to my current organization.

Now, some observers will say, and I can be counted as one of them, that the Gartner EA framework is, hmm, let’s just say “modest” when compared to TOGAF and other federal EA standards. However, that’s not to say that you can’t glean some interesting perspective which can be applied to these more robust bodies of knowledge.

In particular, the concept of “business context” was another one of those terms that, by itself, seemed to ring hollow, or at least embodied a suitable level of vagueness such that it didn’t really differentiate itself to me. Let alone convey its significance. Kind of like how, if you’ve ever said to yourself a singular word so many times in a row that you feel you lose all sense of its meaning and actually start to question your sanity in that moment? That’s what some of these Gartner articles have a way of turning into. A sort of white noise.

Perhaps this is what they meant when they said this layer is the most immature. All you need to do is sprinkle “business” here and there and you might actually convince someone that you really know what you’re talking about. Fake it ‘til you make it, right?

However, don’t mistake my saltiness for lack of interest or appreciation. What actually crystalized this concept for me was the following diagram. As someone once told me, you have to repeat something at least seven times as a leader before the message sinks in. So even though I’ve read and seen this before, perhaps it hadn’t truly registered.

That said, what this diagram illustrates is that the “business context”, i.e., the expression and combined implications of the business’s internal strategy, external environmental factors, and a conceptualized vision of the future shape of the business (Gartner, 2009) should ideally infuse every viewpoint with the EA framework. In this way, business context is less a notional set of ideas, and more of a secret decoder ring that can be used to analyze and map the activities of the EA program and technology teams such that it can foster the alignment between the esoteric and practical.

The mapping of business strategy to the technology-enabled projects in order to realize this vision (Bernard) is not necessarily a new concept. The EA6 Cube and TOGAF frameworks both allow for this top-down or injection of business needs and objectives into the organization’s architecture development activities. However, what I thought uniquely effective in this model is that it highlights this business context as both the overarching raw material input that is needed to guide this process, how it should serve to inform each aspect of the architecture, as well as how it depicts the confluence of each architecture domain as they come together to create the solution, i.e., the final result.

Ultimately, that is the measure of any model’s worth. Does it increase the common understanding of a given subject and facilitate knowledge sharing? Further, can it effectively improve the decision-making activities of the entity that is using it? Does the model have a purpose, and if so, is it being effectively used for that purpose?

Unfortunately, this is where I felt the article dropped off in value a little bit since beyond what I stated above, it didn’t provide much detail around what this artifact, or collection of artifacts (the so-called “Common Requirements Vision”), would actually contain, at least not with demonstrable examples. From what they describe, it felt to me reminiscent of an organizational model. Although, while close, I don’t think that an organizational model by itself was wholly sufficient to convey the business context.

For example, the following organizational diagram includes the primary elements of:

• All manner of inputs that are required for the business to create value or services (Left)
• The external entities that influence, govern, and interact with the business (Top)
• The outputs of the business activities, which can include internal stakeholders as well as external consumers or customers (Right)
• The competitive landscape that business operates in (Bottom)

While this model, to a degree, captures at least one of the aspects that Gartner mentions, i.e., the “external factors”, and may in an abstract way allude to a semblance of the “business strategy”, it is mostly lacking beyond this first component. However, that is not to say it couldn’t also be modified to represent variations of alternative future states to address Gartner’s third attribute of business context. Missing, however, is any internal view of the business operations, especially the value streams.

Although these types of models may be incorporated as a part of the portfolio of artifacts used to document and describe the business context, what is omitted would appear to be the textual expression of the rationale and purpose of the organization that can more fully convey the intent behind the structures represented therein. Simply put, more details are required. On this point, I felt the Gartner article was deficient. Therefore, I will attempt the fill in the blanks with some generalized details from my own healthcare organization.

Typically, every couple of years our business leaders will put together what they call a Mission Action Plan, which, interestingly, includes many of the aforementioned attributes Gartner describes as part of the business context:

The External factors that can influence the business …

• Caregiver population is aging rapidly and is not being replaced in sufficient numbers
• Since the caregiver population skews older, they are typically less technology savvy
• Healthcare delivery models are changing from “fee for service” to “outcome based”
• Federal and state reimbursement rates have not kept pace with escalating costs

The Internal strategy of the organization …

• Pursue new markets such as behavior health that have higher margins
• Develop new approaches to deepen the caregiver candidate pipeline
• Improve caregiver engagement capabilities and retention rates

A Future state vision ….

• Be the provider of choice for all healthcare staffing roles with our key industry customers
• Digitize all paper-based processing for key business processes
• Enable new levels of compliance and auditability
• Grow revenue by 20% annually for the next 5 years

Now, this artifact is nothing more formal that an MS Word document. Point being is that it doesn’t need to be fancy. But as Gartner suggests, having this information in critical for EA to possess in order to be able to successfully align the organization’s activities and deliver the intended business outcomes. Further, the Gartner framework highlights that this lens needs to be applied to all the architecture domains, business, technology, and information, in order to define an appropriate and suitable solution architecture.

But how can I apply these artifacts and requirements to my own enterprise?

Well, I’d be disingenuous if I were to suggest that we have it all figured out. And it is at this stage in the discussion, I usually like to highlight a few things. Likely, you’ve heard them from me before that the application of this approach will at a minimum depend on a couple things:

• The maturity of the organization
• Its stage in the corporate lifecycle
• The organization’s industry and level of complexity
• The orientation of the EA program (technology vs. business, strategic vs. tactical) (Forrester)

These factors will dictate in many ways how EA will need to navigate the inner workings of the organization in order to achieve its goals. In our case, we are somewhat mature in our processes for certain areas, but we are still very much in a sort of “startup” mindset. That is to say the organization is still growing rapidly and solving problems is valued more than bureaucracy and rigorous analysis and planning. To provide additional clarity, we use the Adizes management model as a reference point for strategic planning. This approach categorizes the organizational role functions into Producers (drive results), Administrators (run the process), Entrepreneurs (create the vision), and Integrators (share knowledge). When we sum up all the motivations for our leadership team, i.e., how the individuals view the expectations of their roles, we come up with an aggregate score that is weighted toward the Producer role.

This means that we have an organizational culture that both rewards and prioritizes results. It is left open as to what type of results stem from what activities. However, this culture frequently manifests itself through our tendency to focus, and spend most of our time, on getting to the solution architecture, i.e., how are we going to solve this particular problem. And when can we get it implemented? Reinforcing this the individual personalities that tend to favor reductionist versus systems thinking.

Given that our EA orientation is one that is primarily driven toward influencing “technology strategy”, the EA team’s challenge is how to both understand and infuse this business context into our architecture development process. This can be made more difficult by the fact that we don’t have any dedicated business architects within the organization or practice this as a distinct discipline with any formality. Instead, much of this expertise resides within the business leaders themselves, and by proxy, is conveyed through the Application Service Managers that most directly align with the business services that the business units use. When we conducted a self-assessment using Gartner’s EA maturity model, the lack of business architecture skills was notably identified as a gap.

Regardless, there is still have a need to leverage this business context and apply the direction and guidance laid out in our Mission Action Plan to our product and project initiatives. We never want to do technology “for the sake of technology”. It always needs to be correlated to some business objective. Therefore, I am looking to develop and incorporate this set of business context artifacts into our technology governance structure as noted below. I’ve highlighted with the purple box those forums that operate at a strategic level and in the initiation phase of the delivery lifecycle where I feel these artifacts would be most impactful.

Interestingly, if we had a standardized set of these business describing artifacts, we could also leverage them across the other phases of the delivery lifecycle to assist in conducing impact analysis and growing the business acumen of our team members. This last point is a consistent focus of stakeholder feedback, i.e., that not all team members have a good understanding of the business. The typical response to which is, “then where am I supposed to get this understanding from?”.

While the above commentary is squarely directed inwardly at the technology layer, these artifacts could and should play a role outside the technology governance framework. In our case, I would look to incorporate them into the strategic planning exercises of the business, i.e., the process which actually formulates the business strategy embodies within the Mission Action Plan.

As most CIO’s desire to be more involved in the strategic planning and decision-making activities of the organization, the EA program should take advantage of this opening to position them with such information. Coincidentally, this approach would similarly tie in with the recurring theme of EA, and IT in general, being looked at as a trusted advisor to the business.

References:

Burton, B., Allega, P., Lapkin, A. (2009). ‘Business Context’ and ‘Business Architecture’ Are Not the Same. Gartner. November.

Burton, B., Allega, P. (2011). EA Must Include Defining Your Enterprise Context. Gartner. March.

Barnett, G. (2022). The State of EA 2022 : Market Disruptions Lead To The Resurgence Of Tech Strategy-Driven EA. Forrester. June.

==============================================================================

Confusing Terms and Roles within the Business Layer [6.2]

 

In this week’s previous, I called attention to our organization’s struggle when it comes to focusing on the solution architecture viewpoint at the expense of dedicating time to build a deeper understanding and application of the business architecture within its relevant context. Therefore, I’d like to explore another couple of pitfalls that organizations can fall into and that were highlighted in this week’s readings.

Analyst vs. Architect

No, this isn’t the undercard matchup to the main event. Instead, this first example represents a classic misinterpretation, or perhaps lack of understanding, between two functional roles involved in modeling the enterprise as it relates to the business layer. While both roles may have a purpose in helping to develop the artifacts that describe the business architecture, they operate at different ends of the continuum and will tend to meet in the middle. Hopefully without any fisticuffs.

As you might surmise, the business architect role is principally focused on identifying and selecting the appropriate models in order to assemble a representation, or blueprint, of the business. It is much more intent on illuminating the relationships and the interplay of the various people, process, value streams, and technologies that constitute the enterprise for the purpose of supporting some task such as planning, analysis, or decision-making than documenting the details associate with each individual model. However, that is not to say the architect may not contribute to and develop some of the information contained therein. Perhaps this is the source of some of the confusion as even though the architect may remain engaged throughout the course of the documentation effort, building out the low-level details is not their primary responsibility.

In fact, much of the hard work to construct, refine, and maintain this information usually falls on the business analyst. I’ve intentionally left off the “process” portion of this title, but often this is a principle area of attention for this role.

In our organization, we have numerous business analysts but no true business architects. As I enumerated earlier, this is likely due to several factors, but mostly driven by a lack of organizational maturity and a tendency to prioritize the solution architecture. Since business analysts often create the process flows and functional requirements, this inherently lends itself to interfacing with, and orienting towards, the technology teams so that they can build or configure the technical components to meet the business needs. Given that this is the area that the solution architecture covers, it makes sense that we’ve invested more in this role than others.

The challenge though is to not confuse on with the other, or think that you are doing one because you are doing the other. While business process architecture may be a part of the business layer, simply creating process flows does not equate with developing a business architecture. As the organization evolves and complexity grows, being able to articulate this difference and the need for both roles will have a direct impact on the quality, completeness, and usefulness of the results beyond a particular application or system.

As I’ve found, educating and selling this story can be difficult especially when the status quo seems to be working. For example, do we have a business architecture defined? No. Are we still profitable and growing? Yes. So, what’s the problem then?

This is endemic to the hurdles EA practitioners will always face as to whether the investment in time and energy to develop these architecture artifacts worth the return. For smaller, less complex entities the answer isn’t always as clear as you’d think. However, the opportunity for EA is to tease out the best and core lessons from the larger discipline in order to make a tangible and positive impact on the environment within which they operate.

As one presenter at a Gartner conference once noted, “just because you’re not operating at the scale of Google doesn’t mean you can’t apply some of their lessons”.

Context vs. Architecture

Merging a couple lines of thinking, the common themes in this week’s post highlight both the importance of the business context in informing and guiding EA efforts as well as the not uncommon misconception that the organization is doing something it actually isn’t. Both these points come together in a Gartner article that so aptly states that business context and business architecture are not the same thing. So, for a moment, we will clarify that:

• The business context is the information, and implications thereof, that is used to translate and understand the business strategy, environmental factors, trends, and requirements such that it can inform the activities of the EA program in order to achieve the business objectives
• The business architecture, on the other hand, is the practical structuring and arrangement of the organization’s people, process, and technologies such that they can perform the necessary functions needed to accomplish the business objectives.

If the business architecture was analogous to a wall, it would describe the structural elements, their relationships, and how they work together to accomplish the intended purpose. Conversely, the business context would provide the observer with the reason the wall was required in the first place, the expected benefits resulting from its installation, and perhaps the means to measure and report on its effectiveness in achieving this goal.

What I found interesting is that Gartner indicates that their research shows that the organizations that most frequently confuse these two activities are the ones that have chosen to begin their EA journey by focusing on the technical architecture. Perhaps this is because those organizations that have taken this approach are always looking for the “meaning” behind the technology in order to orient themselves to the business needs. Or perhaps this search for meaning stems from the soul-searching that follows when initiatives do not deliver the intended results. Negative stakeholder feedback can be both a bitter pill and a powerful motivator.

In our organization, I generally don’t see this specific scenario being the primary reason we have not developed a robust and well-defined business architecture. We tend to have a fairly good communication channel between our business partners and technology leaders and don’t really pursue technologies without business awareness and involvement. Although I may not always agree on the particular path the communication takes and the way the information is shared, there is usually a decent alignment between the business context and the technology landscape.

However, there is indeed a lack of supporting business architecture deliverables. If anything, this could be due more to our tendency to prioritize “getting to the answer” and developing the solution as opposed to a lack of understanding the business context. A curious point might be, does this rush to being development omit or overlook the opportunity to better support the business by more closely structuring the solution to align with the business architecture versus the business context? This is a question worth digging into more deeply.

References:

Ulrich., W. (2010). The Essence of Business Architecture. BainInstitute.org.

THE DEFINITIVE GUIDE TO: Business Architect. LeanIX. https://www.leanix.net/en/wiki/ea/business-architect#

Burton, B., Allega, P., Lapkin, A. (2009). ‘Business Context’ and ‘Business Architecture’ Are Not the Same. Gartner. November.