Five principles of solution architecture
in Blog
Author: Arun Thakar is a Certified Master Anaplanner and Vice President in the banking industry.
Whether you are just starting out as a solution architect, or you’ve worked on several models you may benefit from a refresher on some of solution architecture’s key principles. It’s important to remember that these are not exhaustive but are still essential components to your design process. Without further ado let’s dive in!
- Scalability: Your model must be built to last, whether the use case you are working on houses 10 or 100 users. Some key points to consider are using unconstrained list dimensions which grow over time. Try to limit the number of lists with the users dimension in conjunction with other lists that might grow significantly over time. Rarely if ever allow a UX-driven action button as part of the normal planning process, as this can cause the model to hang at a time when users might be furiously working to meet a deadline.
- Usability: When it comes to the how practical the solution is, the first thing that your users will react to is the UX. UX design could warrant an entire article on its own but some key artifacts which drive user acceptance are found up front in the requirements-gathering phase. Things such as UX mockups and acceptance criteria are important for envisioning an end state which solves the problem in a way that users can intuitively interact with. If the process is a series of data transformations over several UX pages, try leveraging breadcrumb icons at the top your page or treating the UX like a wizard which guides the user through steps. If the page requires heavy user input be cognizant of the horizontal and vertical scrolling required.
- Performance: Everyone wants a model which performs fast; familiarize yourself with the Planual and ensure that everyone in the model you are working on is aware of the best practices for designing in Anaplan. Ultimately if a model calculates quickly, it has better chances of being adopted. Conversely a slow model could hinder your efforts.
Check out two helpful model design resources: OEG Best Practice: The model design process and Event recording available! Model design best practices. - Purpose: The scope of a model is usually pre-determined. It is the model’s reason for existing. There will invariably be times when scope creep threatens to dilute or repurpose a model for something which it isn’t designed to do. An example is whether your variance analysis feature should live in a live forecasting model or whether it belongs in its own model. As an architect, ask stakeholders to consider whether the feature their requesting is critical for the first iteration of the model or if it belongs somewhere later in the roadmap.
- Value: The model you built needs to unlock value for the business. One of the reasons for choosing Anaplan as the platform to build your model is to improve or transform the way that the planning process is currently functioning. Keeping in mind the value you are creating for the business may seem ethereal at times, but if you — the architect — design to alleviate administrative burden, or provide transparency, or increase collaboration your model will have broader reach and relevance than it otherwise would have.
Thoughts? Leave a comment!
Tagged:
2
Comments
-
Great Insights, thank you!
1
