Why reinvent the wheel?
I caught up with an old contact recently and we were discussing how the IT landscape has changed over the last few years as more functions are becoming engaged at a business strategic level rather than the traditional order taker. What I found very interesting was my contact’s view of certain functions being more successful at this than others. He highlighted that, in his opinion, Enterprise Architecture as a department is very much established and on “ the executives radar” whilst Business Analysis has typically not reached this level.
This raises the question: what can BRM departments learn from other functions which will help them become more established at an executive level?
Comparing Enterprise Architecture and Business Analysis , the duties/ deliverables for both roles are, according to Wiki:
Enterprise Architect (EA)
· Alignment of IT strategy and planning with company’s business goals.
· Optimization of information management through an understanding of evolving business needs and technology capabilities.
· Strategic responsibility for the company’s IT systems.
· Promotion of shared infrastructure and applications to reduce costs and improve information flow. Ensure that projects do not duplicate functionality or diverge from each other and business and IT strategies.
· Work with solutions architect(s) to provide a consensus based enterprise solution that is scalable, adaptable and in synchronization with ever changing business needs.
· Risk Management of information and IT assets through appropriate standards and security policies.
· Direct or indirect involvement in the development of policies, standards and guidelines that direct the selection, development, implementation and use of Information Technology within the enterprise.
· Build employee knowledge and skills in specific areas of expertise.
Business Analyst
· Business requirements, i.e. business plan, key performance indicator, project plan…
· Functional requirements, i.e. data models, technical specifications, use case scenarios, work instructions, reports…
· Non-functional requirements
· As-is processes, e.g. dataflow diagrams, flowcharts
· To-be processes, e.g. dataflow diagrams, flowcharts
· Data models, i.e. data requirements expressed as a documented data model of some sort
· Business case, a strategic plan containing shareholders’ risk and return
I’ve highlighted in bold the elements I believe have links/commonality to the BRM role, which has led me to the below conclusions and further questions.
1. BRMs can learn a significant amount from EAs for various reasons:
a. There is significant commonality between the two positions.
b. EAs are now generally established at the business strategic level. How have they done this and what can BRMs learn from EAs to help them reach this level?
c. What tools (or elements of tools) are available to EAs that can also be utilised by BRMs to help them along this journey?
2. Where does the EA role end and the BRM role begin? Do the roles/functions need to consider merging?
3. Business Analysis, whilst sharing less commonality, is an established function with established tools including those within (high level) business requirements and business cases. Such tools can help BRMs also become more established and need to be utilised.
4. What other established functions can BRMs tap into? Other business partnering functions? PMO? Who else?
There is a strong desire in the BRM community to become more established at the business strategic level and whilst specific tools and procedures are available to achieve this, we shouldn’t forget there is also a fountain of knowledge available to us via peers in different functions, some of whom have already successfully achieved what the BRM community is looking to accomplish.
Your thoughts and comments are, as always, very welcome.
James O’Driscoll BRMP®
Director – Gilbert Scott Associates Ltd
Share