Select Page

Post 1 –  Business Architecture : Lessons learned by a Solution Architect

According to the Open Group; Business Architecture is the first architecture domain that must be defined while undertaking an enterprise architecture initiative. The reasons for these are fairly straightforward; the organization’s vision (as a profit or non-profit) is to deliver favorable & strategic business outcomes.

One of the tools used in the architecture development method (ADM) is the discovery and definition of business scenarios. These are used to understand the possible conditions and methods in which a service/product is exchanged between consumers and/or organizations (B2B or B2C). The exercise helps all stakeholders realize :

  • The value of the solutions developed to address the business scenario needs
  • The risk of not addressing business requirements
  • Critical capabilities that will define the success path for years to come

As a foundation for Business Architecture, business scenarios need to be SMART i.e.

  • Specific
  • Measureable
  • Actionable
  • Realistic
  • Time Bound

The steps for gathering a business scenario are listed as below according to the open group

  1. Identifying, documenting, and ranking the problem driving the scenario
  2. Identifying the business and technical environment of the scenario and documenting it in scenario models
  3. Identifying and documenting desired objectives (the results of handling the problems successfully); get “SMART”
  4. Identifying the human actors (participants) and their place in the business model
  5. Identifying computer actors (computing elements) and their place in the technology model
  6. Identifying and documenting roles, responsibilities, and measures of success per actor; documenting the required scripts per actor, and the results of handling the situation
  7. Checking for “fitness-for-purpose” and refining only if necessary

 

So what does all the above have to do with solution architecture?

As a consultant who worked on any platforms; the terms ‘best of breed”, “best practices”, “industry leading” are all part of the sales pitch when selling a solution capability to a customer. The challenge from the customers implementing these solutions are always pretty much the same,

“Does this solution cover our business processes and practices?”

The answer to the above question lays out the future of the customer’s architecture landscape and potentially a very successful or disastrous outcome. Why such a bold statement? The reason is simple:

Most solutions are purchased before the needs are even thoroughly vetted. This means the solutions architect is usually gathering business requirements as a part of the implementation exercise. This is fundamentally wrong. The business requirements should be clear and concise before the solution is even procured. The capabilities required by the business reflects the solution selection criteria. Putting the solution selection before the business requirements/capabilities are known is a critical misstep.

How do I know this?

How many time have you seen an instance where the customer realizes the application in question does not meet their needs. You then go down the modification and customization route. At the end of the implementation; all stakeholders agree that the outcome could have been better. Efforts are made to learn from past mistakes. Could we have Enterprise Architecture fundamentals like Business Architecture to help this situation? I’ll let the readers decide.

References:

  • The Open Group for Architecture Frameworks
  • Burton, B. (2013). Business Capability Modeling Helps Mercy Execute on Business Transformation. Gartner. February.

Post 2 & 3 – Operating Models as a foundation for Business Architecture

Part of the reasons organizations have a disjointed architecture practice is because of the ignorance around operating models and/or the reluctance to adopt one. Besides providing structure, process and form to the architecture function, operating models help address:

  • Strategic alignment
  • Short Term focus and silo focus
  • Lack of clarity in vision

This figure shows that a firm's mission can be articulated by a business model that comprises the cost and revenue streams of the business. It implies that a strategy takes a firm on a journey toward its vision and thus will affect the business model. The cost stream component of the business model feeds the business capability map. Initially, the key capabilities identified in the business model are expanded to include a holistic view of all business capabilities that a firm needs to realize its mission. The capability map is then fed to the operating model, where the capabilities are configured to deliver the value proposition within an organization structure. This structure is supported by a management and governance structure to enable sustainable delivery of the value proposition on a daily basis.

The below are the key elements prescribed for an effective operating model

  • Define services to deliver value to customers
  • Articulate capabilities as a means to execute
  • Use Organizational model to deliver value
  • Use Governance protocols to ensure accountability
  • Leverage leadership to provide guidance

This figure shows that an operating model comprises five elements: services, capabilities, organization, governance, and leadership. Starting at the center, the outcome from an operating model is the value proposition. These value propositions are the result of configuring specific business capabilities. The business capabilities will be executed across an organization structure, which will in turn require a management and governance structure to operate sustainably. Leadership provides direction for the mission and vision. All five elements must be implemented and aligned to provide a successful operating model.

References

  • G Barnett, A Cullen, 2013, The Anatomy of an Operating Model