Assessing options on architecture and technology for large project [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

At work we have just secured funding to develop a complex research-oriented information system for internal use. This system will have to support the daily work of over 100 scientists and technicians, manage 10 TB of data, and be available remotely as well as locally. These figures will increase at roughly 10% per year.

I am the designated project manager. Although I have extensive experience in some architectural styles that may be applicable, and some technologies that we may choose to employ, I would开发者_开发百科n't like to embark in the project without careful consideration of all the options available in order to pick the best ones. To this end, I would like to perform some kind of assessment of options regarding architecture and technologies. There are several options to carry out these assessments, such as doing them in-house (affordable but time-consuming, and perhaps not too reliable), asking an external party to do them for us (maybe expensive), relying on existing reports or previous work, or a combination of all these.

My questions are:

1. Do you think this kind of assessment is a good idea before we start with the engineering stage of the project? Is it worthwhile?

2. How do you think we should carry out the assessments? What basic approaches there are, and what are their pros and cons?

Thanks.

---

Some things to do would be:

• Ask the vendors of the technology that you are considering to supply references similar to your case, and talk to those references
• Do a proof-of-concept, using a realistic vertical of what you intend to build

We us Perspective Based Architecture to make these kind of choices, see http://msdn.microsoft.com/en-us/library/bb245776.aspx

---

I would agree with @Shiraz about proof of concept, in particular, ensuring the parts of the system communicate appropriately. It is possible to combine elements of his answer, to gain on both the time front and the expertise front (Details below). I would say that I would view such an assessment as you are contemplating as essential - it could well be the difference between a successful project and a time and money sink.

I have been involved in assessing architectures for a system to serve the need of 3000+ software developers who were developing for multiple platforms. This system was not as data intensive as yours, but we had previously done work assessing database capabilities and sizing for the production system, which was about 50% bigger than your data.

One of the steps we chose to do with the database evaluation was to set up a joint project with academia to assess the performance of very large systems. This was when RDMS were newish, and we could find no-one who had experience of the sort of usage we envisaged. Both parties gained from this; we got the results we wanted at a much reduced cost over consultancy or getting in experts; they got a substantial research project, and funding for it.

The way we went about assessing the architecture for the development environment we drew up a requirements specification and then put it out to tender. However, the element that was distinctive about the tendering process was that we requested those on the short list to present a vertical slice of their proposal at a week long fair with all the other developers there on competing stalls. We then provided opportunities for all the developers attend the fair to ask questions, test out the proposals, and give us feedback on their experiences. About 45% of the developers took advantage of the opportunity, and were able to intensively scrutinize the competing solutions. This gave us combined expertise and difference of views that tapped into the internal resources we had available, and prompted the vendors to provide substantial technical input into the process. It was also extremely quick (about 6 weeks setting up this part of the tender, for 3-4 people, then the week of the fair, followed by a couple of weeks compiling and comparing the data arising from the fair.

I mentioned the question of communication between elements of the system. In both the cases mentioned, it was not enough to have assurance that (for example) both parts used SQL; or that both parties used standardised SQL; or that they claimed to adhere to standards; it was necessary for them to demonstrate that SQL generated in one part of the system could be read and manipulated by another element of the system. This provided a few shocks for both us and the vendors - who often were not as adherent to standards as they claimed.