...
All the necessary information from the DC side to Warren can and should be addressed as a set of simple, unambiguous questions. These questions, in turn, can be divided roughly into three subsets, based on the goal they are meant to achieve. Each subset can be expressed as a more general "umbrella question":
What is are the current infra setup, which components it incorporates and what are - and software components in use and what part they in the plans for the future?
What services are is DC offering and what expectations do they have to Warren?
What is the level of commitment of DC in cooperation with Warren and what expectations do they have to will be the 3rd party software systems alongside Warren?
If these topics are cleared from both sides, the ambiguity and misunderstanding of decisive factors that are the backbone of successful cooperation should be minimizedThe first question of the above three is .
These questions are vital to gather the information that affects the following topics in Warren development:
- Architectural decisions:
- which external libraries, components, and standards to use to cope with the requirements of the majority of DC DCs in the target group?
- How to design the functionality in component systems, so that the we provide the value we claim to be offering, without causing the decrease in quality of services and processes existing there before Warren adoption?
- Marketing content and business value:
- Can we actually offer the functionality we are claiming to be offeringoffer?
- Can we offer the functionality in at a sufficient level of reliability in a particular service domain of a DC?
- Are we doing it in a sensible way, e.g. the development effort is comparable to the actual value the development result is providing?
- Are all the features and functionality we are/will be providing also in correlation with the actual requirements?
- Architectural decisions:
...