Sure seems like it. VMware recently announced the acquisition of SlideRocket. SlideRocket has developed a SaaS application for building, delivering, and sharing presentations online. Sounds similar to Office365 PowerPoint webapp (currently in beta). VMware has also begun encroaching on the PaaS space with the release of Cloud Foundry. Cloud Foundry is VMware's attempt to move into the PaaS space currently occupied by Microsoft Azure and Amazon AWS.
But with the SlideRocket rocket acquisition, this marks VMware move from PaaS (and of course IaaS) to now offering a end user SaaS application. Presumably SlideRocket will eventually be ported to run on Cloud Foundry just like Office365 will eventually run on Azure, if not already.
A recent Forrester report "Sizing the Cloud" seems to confirm this. It shows that global IaaS revenue will peak in 2014. But PaaS, and more so SaaS, is where the future money is, according to Forrester.
It will be interesting to see what other SaaS acquisitions VMware pursues. I wouldn't be the least bit surprised if a SaaS-based word processor and/or spreadsheet acquisition are on the horizon. Or perhaps the SlideRocket acquisition was simply an attempt to excite developers on Cloud Foundry with the hopes of accelerating 3rd party development on it.
Wednesday, April 27, 2011
Sunday, April 10, 2011
Aligning the Zachman EA Framework and the SDLC
Lately I have been looking into the alignment between the Zachman Enterprise Architecture (EA) Framework and the System Development Life Cycle (SDLC).
Zachman is a matrix-based EA framework. The rows are considered stakeholder perspectives or abstractions. Columns represent the different communications questions. At the intersection of these rows and columns are artifacts or tasks, which may produce an artifact in another intersection. Zachman provides a taxonomy for the organization of artifacts. Most organizations will tailor the Zachman framework and the artifacts produced. For example, a combination of intersections at a given perspective (e.g. Planner) may result in one artifact (e.g. Business Case).
On the other hand, the SDLC is a life cycle methodology for the inception, development/implementation, operation and retirement phases of a system.
In general the SDLC consists of the following phases:
In each of the above phases one or more artifacts are produced. For example, in the feasibility or analysis phases a business case along with business requirements may be the resultant artifact. In the Design phase an organization may require UML or Visio diagrams be produced. Like Zachman, most organizations tailor the SDLC in terms of the artifacts produced from the various phases.
So how does the Zachman framework and the SDLC align to each other? Quite nicely in fact. For example, combining the Zachman "Designer" perspective's Logical Data Model (Data/What), System Architecture Model (Function/How), and Distributed Systems Architecture (Network/Where) may result in one SDLC artifact, perhaps called the Solution Design document, that maps to the SDLC Design phase.
Another example may be combining the Zachman's "Builder" perspective's Technology Design Model (Function/How) and Technology Architecture (Network/Where) in a Visio diagram detailing the "as built" implementation. This would correspond with the SDLC Implementation phase.
Organizations looking to implement the Zachman EA framework and align it to their existing SDLC, or vice versa, must spend some time to understand what processes, life cycle phases and resultant artifacts they really require. Once that's complete, aligning the SDLC and Zachman should be a fairly minor exercise.
Zachman is a matrix-based EA framework. The rows are considered stakeholder perspectives or abstractions. Columns represent the different communications questions. At the intersection of these rows and columns are artifacts or tasks, which may produce an artifact in another intersection. Zachman provides a taxonomy for the organization of artifacts. Most organizations will tailor the Zachman framework and the artifacts produced. For example, a combination of intersections at a given perspective (e.g. Planner) may result in one artifact (e.g. Business Case).
On the other hand, the SDLC is a life cycle methodology for the inception, development/implementation, operation and retirement phases of a system.
In general the SDLC consists of the following phases:
- Project planning
- Feasibility
- Analysis
- Requirements
- Design
- Implementation
- Test
- Maintenance
- Retirement
In each of the above phases one or more artifacts are produced. For example, in the feasibility or analysis phases a business case along with business requirements may be the resultant artifact. In the Design phase an organization may require UML or Visio diagrams be produced. Like Zachman, most organizations tailor the SDLC in terms of the artifacts produced from the various phases.
So how does the Zachman framework and the SDLC align to each other? Quite nicely in fact. For example, combining the Zachman "Designer" perspective's Logical Data Model (Data/What), System Architecture Model (Function/How), and Distributed Systems Architecture (Network/Where) may result in one SDLC artifact, perhaps called the Solution Design document, that maps to the SDLC Design phase.
Another example may be combining the Zachman's "Builder" perspective's Technology Design Model (Function/How) and Technology Architecture (Network/Where) in a Visio diagram detailing the "as built" implementation. This would correspond with the SDLC Implementation phase.
Organizations looking to implement the Zachman EA framework and align it to their existing SDLC, or vice versa, must spend some time to understand what processes, life cycle phases and resultant artifacts they really require. Once that's complete, aligning the SDLC and Zachman should be a fairly minor exercise.
Subscribe to:
Posts (Atom)