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
- Identifying, documenting, and ranking the problem driving the scenario
- Identifying the business and technical environment of the scenario and documenting it in scenario models
- Identifying and documenting desired objectives (the results of handling the problems successfully); get “SMART”
- Identifying the human actors (participants) and their place in the business model
- Identifying computer actors (computing elements) and their place in the technology model
- Identifying and documenting roles, responsibilities, and measures of success per actor; documenting the required scripts per actor, and the results of handling the situation
- 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
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
References
- G Barnett, A Cullen, 2013, The Anatomy of an Operating Model
Recent Comments