Business management software: solutions architecture and solution architects, part 1

My friend Viktor Lesiv from Arbela Techologies and I are presenting these days two sessions for the Association of Dynamics Professionals about who are solution architects and what they do on business management software implementation projects. Materials from these events will be posted on http://www.dynamicspro.org in near future. Here I will describe the main concept divided in two parts - fist one is based on our ADP session held on August 18, 2015 and another one will be based on the next session on September 9, 2015.

Implementing business software for many years we have found that a lot of our colleagues don't have a clear understanding of difference between solution architect role and other roles on a project. Sometimes a solution architect is considered just as a most experiences consultant in a team with the same duties as the others. During this presentations Viktor and I present our vision of what exactly a solution architect does, and what is the best utilization for this role. Slides for this article and for the first ADP session you can find on SlideShare .

Software architecture

There are a lot of definitions of software architecture and most of them are good enough for our purposes. Let me cite here ISO standard ISO/IEC/IEEE 42010 "Systems and software engineering - Architecture description":

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

I can just add to this that the difference between terms 'software' and 'solution' here is that term 'solution' in our business also includes how our software are to be used, i.e. the process of solution architecture design includes a feature selection step and solution architect not only designs what is needed to cover existing requirements, but also participates in a process of designing what will be the final list of requirements and the scope of a project.

The role of a solution architect

To define and to describe the architecture of a solution is not the main goal for a solution architect. Moreover in most cases it's not a goal for solution architect at all. The role of a solution architect is to to predict and to solve architectural problems, to avoid architectural risks and to give to project managers, executives, subject matter experts and all the other parties involved in a project enough information to ensure that they can properly plan their own activities regarding best ways to use and to implement the solution.

We can divide the duties of a solution architect into three main parts.

Up-front design

Some features should be designed before we develop and implement them to insure that we won't provide several answers for a single question and that all our decisions are concordant.

Standardization

In many cases architect can develop some standards for a project - what to use and what shouldn't be used. Standards simplify a solution and can make it less expensive and less buggy.

Planning

In general planning of resources and deliverables is not a solution architect's responsibility but a solution architect should participate in planning activities and take responsibility for their technology part. Solution architect provides team with estimations and information on dependencies between features, skills, technologies and so on.

Planning process

Two good examples of involvement of a solution architect info a planning process are feature selection and development of a project roadmap.

The purpose of feature selection process is to get the maximum effect for the customer with the minimum effort for both parties.

The typical feature selection process includes the next steps:

• Describe the main purpose of a solution and collect initial list of business requirements related to this purpose or to a potential solution. All the business requirements should be written down using only business terms, nothing about specific software to be scored from a business point of view. There can be a dozen of main business requirements for a single project, maybe less
• Break each business requirement into main, 'epic' features. Epics should be described in terms what software should be able to do when a business requirement says what the business should get. Epic is a place where the value will meet costs, so if the purpose of business requirements is to get a perfect assessment of a planned value, the purpose of creation of a list of epics is to define the result provided directly by the implementation team
• Break each epic feature into technical features for estimation purposes. Architect don't have to define here each feature in detail, the goal is only to estimate the cost of each epic. So we can say that to craft some functionality we should create two journals, several usual tables and a couple of reports and it will take three man-weeks to make it
• Define main constrains, dependencies and missed opportunities
• The most interesting part - the feature selection itself, that should be performed together with the sales team and with the customer. The result will be a project scope and a list criteria of success for the project. Also all the parties will get a list of features that will be used to plane all the next activities

When we know what and how (in general) will be done on the project we can create a roadmap to precise when we will get the main parts. But maybe now you can ask a good question: "Sorry, are we talking about an agile? In this case our plans for the second half of the project can be changed many times during the first half! It's not agile to create plans long before we start to execute them!". And you'll be right. On any project we try to be as agile as we can end to deliver every single part of a solution as fast as we can and not to invest in those parts we are not doing right now. But when we do anything we should give the name and imagine the scope of our final aim. So the goal for a project scope and for a project roadmap is to give names and to define a shape.

Project roadmap is a description of main milestones - names, dates, and lists of activities external to the project that are linked to a certain milestone. We should include there planned changes for customer's business, our planned marketing activities, planned team changes and so on to ensure that every part of our solution will be used upon release and the we are ready to deliver the solution in a planned timeframe.

In the second part of this series we will describe some techniques usually used by solution architects in their work - estimation, technology mapping and working with feature changes and with risks. Your feedback here in comments, on slideshare or to Viktor's and mine emails will be greatly appreciated.