A Hybrid Business Analyst and Architect is someone who thinks both intuitively as well as analytically. Take payment solutions example, you design the payment solution, you makes sure that this solution is a major transformation to the business and delivers the solution within the budget on time. You find out if there is any bottleneck and fixes it and you work along with M&A and improves the value. So now you are the person who works on Business Improvement, Business Transition and Enterprise planning.
Won’t it be just cool?
So now you are a Business Architect . Please don’t mix this with Enterprise Architect, an Information Architect and a Process Architect
Business Architecture is a model which integrates all information that would help a company to function. It’s easy to get it confused with Enterprise Architect. The simplest differentiation is that Business Architect defines ‘what’ and Enterprise Architect defines ‘how’.
So let’s see some important way of a good business model.
- Unambiguous. If anything can be interpreted in more than one way, it will be—resulting in inconsistent behaviour and information.
- Complete. The model must specify the business rules, processes, and information required to build the system. The architect must ensure that this includes everything that needs to be common across applications. However, do not confuse completeness for detail. The model should contain business information, not implementation detail.
- Consistent. The business model must be consistent with both itself and the enterprise requirements. In addition, it must be kept up to date, as requirements evolve during project implementation.
- Traceable. Processes and entities in the business model should be traceable back to requirements.
- Agnostic. The business model is a statement about the business and specifies what will be implemented. The solution model is a statement about the system and specifies how it will be implemented. You must maintain this important separation of concerns.
What we do currently is the elicitation, collection, and specification of requirements trying to put those requirements into a strategic context. The Business Architect will think across projects and interjecting enterprise requirements into the business-analysis activities that is, acting as a bridge between enterprise and project concerns. Also, a Business Architect can help to better express requirements, in terms of formal models that can be unambiguously implemented by the project-development team.
Don’t forget this important thing; Hey Badass Business Architect, you define ‘what’ in an organizational context, not ‘How’.