Conceptualizing architecture, both solution and technical, is extremely important to successful transformations. More important however is the ability to conceptualize processes against the backdrop of architectural decisions and directions. You may say that this is counter intuitive as business process requirements should drive the conceptual architecture and I would say, in a perfect world and an empty green field,  you are correct. However no matter how much prep work goes into the definition of business process requirements, decisions made in the early stages of the technical and solution conceptual design and existing legacy architecture and applications will have effects on the progressive elaboration of new or redesigned business processes. These effects may not be truly realized until more detailed process and technical design work is completed and new requirements are flushed out, which only amplifies cost and effort.

How to avoid these impacts? For me it starts early on in business process design. Once a new solution has been defined the development, elaboration, or clarification of the business process requirements need to be completed in the context of the selected solution, existing infrastructure and previously defined conceptual solution architecture. Engaging solution architects, knowledgeable solution experts, and educating the business and project leads from your organization on the abilities of a chosen solution is key to early identification of business requirements that may not be realized as initially thought within a give solution.  Educating technical resources responsible for the technical architecture is just as, if not more, important.

Additionally all previously made enterprise technical decisions need to be evaluated against the selected solution. Specifically, assumed functionality from legacy applications needs to be assessed agains the functionalities of the selected solution and changes to the conceptual architecture assessed. More often than not an enterprise will try to turn a selected application on its head to accommodate a previously made enterprise architectural decision or what is assumed to be a legal system “sacred cow”. In my experience this is most commonly found in the management of enterprise master data, security definition and interaction, and enterprise data warehouses integration. Exceptional efforts and costs are expended to keep previously made architectural decisions in place when the best decision may have been to replace them with the offerings of the new solution.

Again the ability to conceptualize the solution and technical architecture requires a clear end-to-end business process view. It also requires the ability to challenge existing enterprise architecture and legacy applications. Putting it all together early  on ensures that rework and additional costs are not incurred. However reducing the time and cost of implementation may mean having to rethink previously established enterprise decisions.

Successful transformations will take the time to define the conceptual architecture, identify areas of convict with the existing enterprise architecture, and make informed decisions based on best practice and reduced impact to the implementation of the new solution. Creating and maintaining a solution planning team within your program that takes on the progressive elaboration of the solution implementation, drives down a couple of levels on the process and defines the conceptual solution and technical architecture which supports the conceptual process can save time and money by providing deeper context to business requirements and leveraging the existing resources to your best advantage.