IT Projects Success - Principle #3: Use Architecture to describe the business, before and after projects.
Continued from:
http://blogs.itworldcanada.com/insights/…
3. Use Architecture to describe the business, before and after projects.
“Architecture” is becoming a more widely used term associated with Information Technology. The number of adjectives applied to the term seems endless: “Technical Architecture”, “Systems Architecture”, “Business Systems Architecture”, “Enterprise Architecture”, and so on, so it must be important.
Why do we need Architecture?
Architecture is not an end in itself; Architecture exists because things need to be built.
Architecture is required when building anything that is not simple; in its essence, Architecture identifies all the separate components of an end product and how all the components are related and fit together to comprise the whole of the product.
Architecture is layered to capture and present information about the product to different audiences, from initial/high concept to detailed specification.
Applied to IT, a component assembly approach is dominating the industry, from the OO approach of software development, to real-time use of defined services, as popularized by SOA. Specialized agent software is starting to assist in finding services and brokering between different services to perform transactions collaboratively.
For the average company using IT, architecture is needed because it needs focused IT functionality to deliver the highest current value, while trying hard to ensure that the function will work (“integrate”) with the next function that is needed.
It should be emphasized that this is Architecture for Information Systems.; there are methods and approaches being promoted for an overall “Business Architecture”, architecture for the whole business, not just IT. Originating from IT circles, they often look like an IT/IS architecture, which can be confusing. The Architecture in this book is definitely about Information Technology and Systems.
The good news is that you do not need to invent an IT Architecture method for your company. Many authors and vendors have methods available already. When starting out, I recommend investigating/adopting the architecture that started it all, the “Zachman Framework” as developed and enhanced by John Zachman.
(see www.zifa.com for details)
He devised the illustrated matrix framework that cross-references core information concepts against the levels of abstraction that are used by different audiences and participants in delivery of Information Systems.
The key benefit of the framework is that it illustrates how information concepts can be transformed through the levels to produce operating components of the needed Information Systems.
Last two points on Zachman:
- The cross points of the Concept columns and Abstraction rows are called “Cells”; each cell will group the methods or documents (artifacts) that describe the content of the cell. Zachman does not specify what artifacts to use, or what methodologies to use to create the artifacts. The things in each cell on the diagram are just suggestions. Keep this in mind for Principle #10.
- The Framework looks two-dimensional, but it is actually multi-dimensional when artifacts in one cell are cross-referenced to artifacts in other cells, the most obvious example is What vs. How, i.e., what function creates specific occurrences of data.
---------------------------------------------------------------------------------------------
IT Projects Success - Principle #4: Pick the right project(s) for the business.
Continued from:
4. Pick the right project(s) for the business.
At any one time, the IT department of an average company is running multiple projects. How did they get started? How were they even defined as a project that needed to be carried out?
No one may actually know. In more chaotic environments, projects can start as a seed of an idea, pick up momentum and resources if a manager or two can see that they will benefit from the project. At some point, the project will bump into another one, usually because they both want the same IT staff or other resources. Strong managers can often come out of these resource conflicts with what they need for their project, while the other managers suffer from their project going on hold or being cancelled. Otherwise, the conflict is escalated until one common, higher manager has to step in and decide who gets what; and this is often the first time the higher manager has even heard about the projects.
I sat in on a senior management committee meeting where the progress to date of a grand project was presented and a request for a budget increase was made to complete the project. The CEO took all this in, and commented that this was very interesting, but given the sizable amounts of money and time expended so far, why the heck had he never heard of this project before?. The next week my manager sent me to see the CIO, who charged me with coming up with a new process for defining, approving, and controlling IT projects, better known these days as ‘Project Governance’.
So, how do you pick the ‘right’ IT projects? First you have to make the choice explicit, avoiding the random start-ups described above; do encourage any and everyone to suggest possible projects. An active strategic and operational planning process will also tend to drive out new projects as senior and middle management look for IT assistance to reach their assigned goals. All these proposed project ideas then become input to a ‘gating’ process, supported by means of valuing the worth of a project like, but not limited to, cost-benefit analyses.
