Making Architecture and BRMs Successful


By Paul Preiss

I regularly get asked to describe the optimal relationship between the business relationship manager (BRM, also known as client service directors, customer account managers, etc.) and architects, especially as business architecture continues to grow in adoption. Of course my first answer is a resounding "it depends", but then I help organizations clarify. The BRM is the traditional IT link into business planning, providing account management capabilities from an IT resourcing and scheduling perspective, but also a great deal more. Seasoned BRMs have deep domain knowledge, strong business relationships and a clear understanding of costs, budgets and resources. They are at worst order takers for 'the business' and at best, strategic resources with a strong business outcome perspective - often one of the strongest business outcome perspectives with any direct involvement in IT. In fact, like business analysts, they often end up becoming business architects themselves. But what is the difference? And if an organization wants to adopt business architecture as a practice what should the relationship be with the BRM?

As I said, the answer is always, always, always, it depends. However, I can describe many of the traits of the more successful outcomes I have seen as well as some anti-patterns where failure or major problems are more likely.

There are a number of current struggles organizations and members have come to discuss with me. Many of them are process focused but others are political, as would be expected in developing architecture past the IT optimization phase of maturity. For example, I met with one fortune 100 where the architecture function does not reach outside of IT except for the minor business relationships formed during the delivery of IT projects. They have very strong BRMs who view the business units as their 'customer' and do not tolerate others to participate in meetings or planning unless it is a very controlled technology question being discussed. This organizations enterprise architecture team is very capable and has been developing roadmaps, strategic plans and investment proposals for some time. They originally took Iasa training 3-4 years back and internalized the strategic planning cycle very quickly. However, they have been unable to make headway into the business prior to project delivery. We very quickly identified the BRM as the critical force in holding them back and put in place a plan for how to begin moving that relationship forward. In this case, the EA team had decent executive support and some solid successes under their belt so they were able to take a more direct approach (they worked through IT management) to open up the gates, however in organizations where architects have yet to demonstrate their value, this will be more difficult and a support to success (align architects to BRMs in more supportive role) maybe necessary.

The other aspect of the relationship is when should architects be brought in? This also includes opportunities to install architecture directly in operations, business units and strategic planning more directly. In these cases it is essential the roles be clarified. Business architecture is a strategy creation role, where BRM and PMO are project and delivery roles which is focused on execution. In the optimal world the BA and BRM will work side by side, one focused on the future of business and the other on execution. But keep in mind there is an architect focused on execution as well, the solution architect. It is absolutely essential that the BA and SA be deeply connected, beyond mere title. As a solution architect, I used to refuse assignments where I did not have buy in to the development of the expected outcomes. Solution architects should be project focused but make sure to bring them in early enough to ensure they have a stake and a say in the outcome (such as during business case finalization).

With all that being said here are some general do's and dont's of the architect to BRM relationship.

Do

  1. Align the BRM and the Architect (Business Architect if possible, EA or TA if necessary)
  2. Ensure Architecture and BRM are working at the same level
  3. Ensure both have access to the same business owners
  4. Create a roadmap which links outcomes, capabilities (business and technical), and processes to schedule and resources.
  5. Allow the BRM to manage and the Architect to create/innovate - notice those are capitalized. Align Architecture to Strategy and Creating Outcomes. Align the PMO to Delivery, Cost and Requirements
  6. Ensure there is an architect involved in the planning cycle prior to business case development.

Don't Do

  1. Allow BRMs to control business relationships - while that is in there title, the function is a planning and execution focused element of the PMO. It is not a strategy setting role. Without open and clear communication between architects (of all types) and other business units the innovation, creation, and strategy side of the architecture job cannot be accomplished.
  2. Bring in solution architects to 'design' the project after it has been started.
  3. Make BRMs into business architects without the appropriate skills.
  4. Put architects in charge of managing projects and programs instead of BRM and PMO.

 

Upcoming Events
Event
Architect Core - Online October 2020 10/13/2020
VIEW EVENT
Integration - Online NOVEMBER 2020 11/24/2020
VIEW EVENT