Usually there are at least 2 interfaces involved in designing a web application (SaaS) or internal/intranet application
- Public facing – Product information and signup/registration process
- Application – The application/service being used, usually protected by a logging-in process
- Administrative application – An internal-facing application that is used for administering the application.There are 2 approached in this regard – combined functionality or separate.Reusing the existing application and including administrative features into it cuts down on development effort but increases risk for vulnerabilities and exploitation.Creating a separate application might require additional efforts, but this can be secured by using various security features and mechanisms (IP whitelisting, trusts hosts, firewalled appliances etc)
For each of the interfaces that are required, the following should be considered:
The last year or so we’ve been doing alot of mixed technologies for projects on REST web services written in either Microsoft technology stack or the open-source technology stack (LAMP), and what I discovered that the principles and disciplines are the same no matter what environment you work in, just the semantics (language/platform) that is different.
The company I was contracting to at the time had reminded me how easy it is to overlook certain elements of a project when designing a new system. The System/Application Anatomy (S/AS) was my first attempt to document and understand all the various influences that complicate the development efforts in the life-cycle of a system. This was before the implementation of SCRUM (project management at the time was Waterfall) and the developers tend to look at the “Functional implementation of requirements” only for estimation and planning (and as a result only portions of that). By expanding on the section, I tried encourage the developers in the team to consider all the factors that might influence their estimations.