ERP solution architect role, part I
Download as PPTX, PDF2 likes1,360 views
The document discusses the role of a solution architect in agile projects, outlining their responsibilities, deliverables, and the importance of software architecture. It covers project planning, technology selection, and estimations, emphasizing the need for tailored solutions based on varying team qualifications and project complexities. Additionally, it details the process of feature selection and product roadmap creation to align customer requirements and project execution.
ERP solution architect role, part I
- 1. dynamicpartnerconnections.com Dynamics AX Consulting Expert Series Solution Architecture of Dynamics AX The role of a solution architect on an agile project, part I Viktor Lesiv Director of Technology Arbela Technologies Viacheslav Nefedov Program manager Celenia Global Services Presenters
- 2. The authors 2 vin@celenia.com viktor.lesiv@arbelatech.com Viacheslav Nefedov Celenia Global Services Program Manager Viktor Lesiv Arbela Technologies Director of Technology
- 3. The topics Session 1 – Definition of Software Architecture – Responsibilities and deliverables – SA role in project planning 3 Session 2 Technology selection Estimation technics Working with requirements Now September, 9th
- 5. What is Software Architecture According to ISO standard ISO/IEC/IEEE 42010 "Systems and software engineering - Architecture description": 5 Architecture is a fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution
- 6. Solution architecture The big difference between a piece of software and a solution is that there will be different solutions for a single problemset and to define a solution also means to perform a feature selection and to find an optimum project scope.
- 7. What an architect does Does • Defines main design decisions and standards Responsibility • Solutions possibilities and restrictions • Defining or resources, software, environments, skills needed to develop software • Estimation 7
- 8. Sample deliverables • Up-front design • Designing of solution scope and definitions of success (together with a product owner) • Technology mapping • Standardization • Development and adjustment of design standards • Planning • Estimation • Participation in a project roadmap design • Defining demands in skills and environments 8
- 9. 9 2. Architects and responsibilities - Case studies 9
- 10. Big project, low-qualified team Project • Big holding company, more than 30 legal entities • Automation of finance and accounting • Low qualification of consulting team Solution Use a team of solution architects to: • Prepare work estimation and roadmap • Make a fit-gap report, define list of epics to develop • Monitor and finalize if needed all the Functional Design Docs • Take the responsibility for the solution design 10 Risk!
- 11. Complex project, hi-qualified team Project Development of warehouse solution with mobile computers, reach trucks and warehouse optimization tasks Hi-qualified team of consultants, all the requirements and solutions are clean for the team Solution No dedicated architects Regular architecture meetings are used instead 11 No upfront design needed!
- 12. Brand new platform (problem) Project Transfer of a big solution to a new platform Technology approach is changed Technologies used are very new for the team 12 No standard solutions!
- 13. Brand new platform (solution) Solution advisors (technology experts, RnD) team is used to: • Prepare technology mapping • Take responsibility for new kind of tasks – technology gaps Solution architects team • Defines milestones and roadmap for the project together with the product owner and the project manager • Defines design and development standards • Prepares epics 13 Technology Design
- 15. Feature selection Gathering of requirements Technology mapping and estimation
- 16. Feature selection path 1. Define the big initial list of business requirements and value each requirement and each epic feature inside the requirement in man-hours or in money from customer’s point of view 2. Split each epic feature into features that can be estimated, give estimations and give the customer possibility to compare features by value and costs and to select the final feature set
- 17. Voice of the Customer form Customer Voice of the Customer Business requirement Value Who is the Customer? What does the customer want to be able to do using the product? What should the system do to meet voice of the customer? What is the definition of value for the customer? Voice of the Customer collection form
- 18. Business requirements breakdown form Business requirement Value of BR (in value points) Functional epic Weight of epic Value of epic (in value points) Create loyalty program management module 2000 Loyalty program management console 100 200 Create loyalty program management module 2000 Loyalty cards data storage and hands-on processing 700 1400 Create loyalty program management module 2000 Loyalty card scanning 200 400 Business requirements breakdown form
- 19. Glossary for requirements 1. Business requirement - the goal of the solution described in terms of business usage. Product is done when it fits business requirements 2. Functional requirement (feature) - description of the solution's feature, e.g. credit card processing module for creation of payment journals 3. Epic features - main features, that are known before the development process starts. In most projects 50-70% of functionality is covered by epic features. All the other features are either subfeatures for epics or are necesary to cover business requirements
- 20. Roadmap creation • Releases with dates and names • List of features for each release • Plan how each release will be promoted and used
- 21. Product roadmap's goals 1. Limit timeframe to deliver parts of the solution to minimize costs by defining milestones, names and epics for every milestone 2. Limit technology usage for every stage of development to maximize ability to communicate between team members by defining technologies and modules for every stage 3. Provide customer with some dates to ensure possibility to synchronize product development with related tasks (marketing, business process changes, business model changes and so on) 4. Ensure possibility for managing project resources (peoples, knowledge, environments and so on)
Editor's Notes
- #2: ©2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.