Application Development and Lifecycle Improvements
[This is prerelease documentation and is subject to change in future releases. Blank topics are included as placeholders.]
The code name “Oslo” repository supports many improvements throughout the application development lifecycle. These benefits include:
Improved communication with reduced loss of information between each stage of the development lifecycle.
An understandable end-to-end view of an application.
The “Oslo” repository provides a central storage location for models at various points in the development lifecycle. This improves communication among everyone involved with the application, because they all share common tools to view and manipulate the application models.
Previous enterprise application development processes already use many types of models, implemented in Visio, Excel, Visual Studio, and various other tools. However, inefficiencies arise due to the translations between these tools and the varying skill sets of the individuals working with them. There is often a loss of accuracy and intent as information flows between stages. This results in longer development cycles, higher costs, and less control over the quality of the end product.
Consider the various people and their different roles on a distributed application development team. A business analyst creates business requirements in Visio and then shares these with an architect. The architect creates a technical plan for meeting those requirements, possibly using Visio as well. When the development process begins, the developers need to translate these models into implemented services and binaries. The developers might work on their own models, such as a workflow. The project now consists of models created by different people in different roles using different tools. There is also no standardized way to store these models so that they are easily discoverable in the future. With this process, there is a higher likelihood of disconnect between the business needs and the production application. These inefficiencies directly result in longer development cycles.
Having a central location for all of these models, along with common modeling tools and skills, improves communication on the team. When an application is first conceptualized, the business analyst stores business requirements and processes into the “Oslo” repository. The architect uses the same “Oslo” repository-based tools to construct a logical design for an application that meets these requirements. The developers take that design and begin to extend it to develop the solution that fulfills the design. Each person in this collaborative process uses the same modeling tools. Having the “Oslo” repository act as a central location for these models also enables a connection between the design and implementation models. This connection helps prevent these models from becoming disconnected during the development process. The use of the “Oslo” repository does not end after the application is created. IT professionals also use the “Oslo” repository during application deployment and monitoring, using the same tools and skill sets. The “Oslo” repository is the common store that enables the code name “Oslo” to provide a platform for seamlessly designing, deploying, and managing distributed applications; this improves communication among all roles during the application lifecycle.
The “Oslo” repository enables enterprises to have an end-to-end view of distributed applications, something that was difficult to obtain in the past. Previously, any high-level view of a distributed application would require piecing together information from various tools and individuals. It is unlikely that any one person could easily understand the application as a whole. With the “Oslo” modeling platform, the distributed application is described in the “Oslo” repository, and Microsoft code name “Quadrant” enables individuals to view and change the application in a rich graphical environment.
Leveraging the “Oslo” repository as a central store, users can find and examine application design and implementation details from any stage of the development lifecycle. For example, an architect could use “Quadrant” to view the models that describe how the application is deployed. Although the architect mainly works on application design, the shared tool and skills enable him or her to directly view various parts of the implementation and deployment. This includes the servers that host various services and their configuration. It is important to recognize that these production models are not merely a representation of the IT team’s understanding of the application; instead, they are models that are actively used in the deployment and management of the distributed application. With one tool, anyone can review the business requirement, implementation, and production status of the application. “Quadrant” also provides different views on the same underlying “Oslo” repository data, so that users with different goals can see the data in a way that best works with the given task. This improves the chances of spotting errors or potential improvements. This understanding of the application also increases the speed and accuracy of assessing potential changes to the application.
Although this type of end-to-end view is desirable for some individuals, “Oslo” repository administrators also have control to restrict data visibility or editing permissions to specific users and roles.