How Many Architects Does It Take to Screw in a Core Banking Transformation?
I was in a meeting recently and everyone at a table of 15 was some sort of architect. There was the print service architect, the enterprise content architect, the security architect, the solution architect, a technical landscape architect, and multiple enterprise architects. Trying to sort out where one architects responsibility ended and another’s began was extremely difficult. It seemed to me that now days everyone wants to be called an architect. The problem is that once a title like architect is given out people start to act like…well, architects. What I mean by this is that when you are called the architect of print services you start to develop a point of view and an architecture that centres around print services sometimes without thought or concern related to business requirements or integration. Sometimes all you’re concerned with is the best best-of-breed printing services architecture you can design. I also find that enterprise architects that stay within enterprise architecture in the run the bank space tend to have to little skin in the game of a core banking transformation to be of significant help and in fact tend to be a significant hindrance. So how many architects does it take to screw in a core banking transformation?
For me there are five central types of architects that should act as a cohesive architectural team within a core banking transformation. I will list them in order of importance:
- Business Architect
- Solution Architect at the Enterprise Level
- Business Architect from the Vendor
- Solution Architect from the Vendor
- Technical Architect
1. The Business Architect
Entrusted by the enterprise to ensure that strategic intent finds it s way into tactical applications of functionality. Owner of the business process, knowledgeable in the current process designs, organizational structure, strategic intent, business cases, able to locate process artifacts. They are able to communicate all of this to an extended team. The business architect also needs to have and champion the banking processes of tomorrow. Based on the scope of an initiative the Business Architect can have a team, but the team is made up of specialist within a process not additional architects. When future processes have to change course from the initial intent or direction it can only be the Business Architect that makes the call. Wikipedia does a nice job of outlining the view and knowledge of an organization that a Business Architect should possess:
- Business Strategy view : captures the strategic goals that drive an organization forward. The goals may be decomposed into various tactical approaches for achieving these goals and for providing traceability through the organization. These strategic goals are mapped to metrics that provide ongoing evaluation of how successfully the organization is achieving its goals.
- Business Capabilities view : describes the business functional abilities expressed via business services of an enterprise and the sections of the organization that would be able performing those functions. This view further distinguishes between customer-facing functions, supplier-related functions, core business execution functions, and business management functions.
- Business Knowledge view : establishes the shared semantics (e.g., customer, order, and supplier) within an organization and relationships between those semantics (e.g., customer name, order date, supplier name). These semantics form the vocabulary that the organization relies upon to communicate and structure the understanding of the areas they operate within.
- Business Operational view : defines the set of strategic, core and support operational structures that transcend functional and organizational boundaries. It also sets the boundary of the enterprise by identifying and describing external entities such as customers, suppliers, and external systems that interact with the business. The operational structures describe which resources and controls are involved. The lowest operational level describes the manual and automated tasks that make up workflow.
- Organizational view : captures the relationships among roles, capabilities and business units, the decomposition of those business units into subunits, and the internal or external management of those units.
2. Solution Architect at the Enterprise Level
Go to the enterprise architecture team and find the one resource with the broadest experience and knowledge of the existing banking solutions. Find out if he or she gets excited about the prospect of change and only shows loyalty to innovation. If you can find this person tell your executive sponsor the project can’t succeed with out them then task them to be the Enterprise Solution Architect for the initiative. Enterprise service design, enterprise legacy integration, and any other cross overs with the run the bank and legacy systems becomes their responsibility. Providing the link to enterprise, defining integration architecture, and building the team on the legacy side to support the transformation are key deliverables for this person. Education themselves and the enterprise on the new solutions and becoming a champion of the new solution architecture is their main goal and responsibility. Again they can build out a team of experts within the legacy solution and foundational architecture deliverables however they should be the single voice on legacy and foundation architecture.
3. Business Architect from the Vendor
Probably the hardest to find resource. The vendor’s business architect should understand end-to-end and best-0f-breed processes from the new solutions point of view. They should be bankers with real life process design and implementation experience with the new solution. They should be able to work hand and hand with the bank’s business architect to help bridge the gap between what the bank would like to have in a new business process and what is possible within the new solution. A knowledgable business architect with deep experience with a specific solution can help a bank leverage their investment in a new solution by ensuring all available feature, functions, and business benefits of the solution are clearly understood and taken into consideration when defining the future business processes of the bank with the bank’s business architect.
4. Solution Architect from the Vendor
Like the solution architect from the bank the vendor’s solution architect should have deep knowledge and experience with the vendors solution. They know all the integration points and best integration methods. They know how all of the business processes are supported by the solution. They know how to integrate the solution. They have deep ties with the vendors product group. They will work hand and hand with the bank’s solution architect to define the end-to-end solution architecture that supports the new solution.
5. Technical Architect
They prepare and support the technical architecture for the new solution. They should take requirements from the solution team and ensure that the technical environment including all required systems are present and available.
Summary
In a well run core banking transformation the bank’s business architect, bank’s solution architect, vendor’s business architect, and vendor’s solution architect become an extremely strong cohesive team. In the end it is almost impossible to tell the difference between them. In the most successful implementations I have been involved with I have seen a bank’s business architect, someone that came from the front line of the bank’s retail operations, explain an end-to-end retail lending account origination process visually via screen shots while calling out and explaining the enterprise services called at every button push. I have also seen a vendor’s solution architect defend the process design approved by the bank’s business architect by linking the decision back to the expected outcome stated in the business case.
I would never want to diminish the effort or skill of specialist on core banking transformations but the architecture team should be small and cohesive. It should actively manage, review, and approve integration points and designs from other foundation groups. Successful transformations will limit the size of their architecture group and will hand out the title of architect sparingly.
