What is IT Architect

IBM Confidential © Copyright IBM Corporation 2008. All Rights Reserved

IBM and WebSphere are registered trademarks of the International Business Machines Corporation in the United States, or other countries, or both. Other company, product and service names may be trademarks or service marks of others.

?What is ITArchitect

Cao [email protected]

mailto:[email protected]

2IBM Confidential © IBM Corporation 2008 All Rights Reserved

Module outline

Misunderstanding to ITA

The most fundamental capability of ITA

Fundamental capability of ITA

Relationship with other profession

Case study

Recommended books for ITA



There are a lot of misunderstandings to ITA: ITA is a technical specialist

ITA is a pure technical job position

Only large scale project needs ITA


Module outline





Case study



What is system thinking?

The most fundamental capability of ITA: system thinking, but not technology

Think from business point view, but not from technical point view

Transmit from business to technology smoothly, but not jump from business to technology directly

Focus on the whole system, but not sub optimize

Systematic method, but not trial and error method

Think big, act small


Module outline





Case study




Consulting capability

Abstracting capability

Hands-on capability

Leadership capability


Consulting capability

Requirement trap

What is requirement

What is stakeholder


How to gather requirement?

Ok, if you’re not cheating me, there will be one bird in the tree if dead bird stay in the tree, if fall down, then no one left.

Absolutely.

All birds can fly freely?No.

Is it possible to kill 2 bird with one shoot? Or more?All fear death.

Any bird stupid or fear no death?Yes, 10 bird.

Are you sure it is 10 bird?Definitely not.

Impossible to pregnant for all birds?All is male.

Is any bird pregnant?No, very healthy.

Is any bird disability or too hungry to fly?No.

Is any tree nearby， is there other bird in the tree?No.

Is any of these birds in cage?No.

Is any of these birds deaf?No.

Does shooting bird break the law?Yes.

That is to say it will hurt ear?80~100 decibel.

How noisy is gunshot?No.

Is silent gun?There are 10 birds in the tree, shoot one bird, how many birds left?


Requirement trap

Requirement is not just what customer tell you to do, what customer tell you is often intuitive, messy, unorganized, sometimes self-contradictory

Requirement seldom appears on the surface

Usually requirement is buried deep beneath layers of assumptions, misconceptions, and politics


What is requirement?

Requirement has levels: business requirement, system requirement

Prior to implementing a solution, we has to understand what the business is, and the business value in implementing a solution

Business requirement is about business event, business actor, business process, business entity, business rule etc, describe business from an external viewpoint

System requirement is the system must do or a quality it must have, describe system from an external viewpoint

System requirement is transformed from business requirement after balancing system stakeholder expectations: technology, schedule, budget, regulation, policy, standards, data volume, usability, extendibility etc.

It is hard for customer to distinguish business requirement and system requirement


What is system stakeholder?

System stakeholder is not necessarily system user, different stakeholders have different needs for the same system

Main system stakeholder and needs:

The end user: intuitive and correct behavior, performance, reliability, usability

The system administrator: administration, and tools to aid monitoring

The sales: competitive features, time to market

The customer: business value, cost, and schedule

The developer: clear requirements, and a simple and consistent design approach

The project manager: tracking of the project, schedule, productive use of resources, and budget.

The maintainer: comprehensible, consistent, and documented design approach, easy to maintain


Abstracting capability

Summarize the essence of problem from complex phenomena of problem , search for problem’s inherent nature, refine conceptual model from deeper insight

From requirement to model

What is conceptual model

What is conceptual integrity


From requirement to model

The overlap between requirements gathering and systems modeling varies as the development of the product progresses. Initially, very little modeling is done, and the majority of the effort focuses on gathering and verifying requirements. As development continues, the modeling activity expands to occupy a continually greater proportion of the effort.

Proportion of effort

time

Requirement gathering

System modeling


What is conceptual model?

Conceptual model identifies the key concepts, and the domain-vocabulary of the system being modeled. The model identifies the relationships among all major concepts within the system, and usually identifies their important behaviors and attributes.

An important benefit of a conceptual model is that it can be effectively used to verify and validate the understanding of the problem domain among various stakeholders of the system. It is especially helpful as a communication tool and a focusing point between technical and business teams.

A good conceptual model excludes those elements that are not relevant to the problem domain level of abstraction.

Conceptual model is not database model!


What is conceptual integrity?

Conceptual integrity means that the system's central concepts work together in a smooth, cohesive way to maintain system usefulness over time

Conceptual integrity is the most important consideration in system design: make a system easy to use and maintainable. Every part of system use coherent model, strategy, pattern

Conceptual integrity dictates that the design must proceed from one individual, and does not separate the design into many tasks done by many individuals


Hands-on capability

Technical trap

Knowing and doing come to be one

KISS principle

What is separation of concerns

What is high cohesion, loose coupling

Passion for beauty of software

Trade off


Technical trap

Technology is not a critical factor as many people think

Only if technology is applied reasonably, linked to a simple, clear, and coherent concept which is understood well, technology will become an essential driver to accelerate your success

If technology is not applied reasonably, and only thought of as a simple solution, without deep understanding of how to apply technology to a coherent concept, technology will simply become a tool to accelerate your failure


Knowing and doing come to be one

ITA don’t just write PPT and proposals

Understanding of the technology is essential for developing a good design

Programming into a language, but not programming in a language


KISS principle

Keep It Simple and Stupid to avoid unnecessary complexity

It is easy to make a system complicated, it is difficult to make a system simple

It is a challenge to solve a complicated problem with a simple solution, but not a complicated problem with a complicated solution

Make system so simple that there are no bugs obviously, but not make system so complicated that there are no obvious bugs


What is separation of concerns?

Breaking down a complex problem into smaller problems so that the smaller problems can be solved individually and separately

A module can be optimized independently of other modules, so that failure of one module does not cause other modules to fail, and in general to make system easier to understand

Methods of breaking down a complex problem: partition and layer


What is high cohesion, loose coupling?

High cohesion, loose coupling is the principle of breaking down a complex problem

Cohesion is a measure of how strongly-related each module internal of a system are

Coupling is a measure of how strongly-related or dependent different modules of a system are

High cohesion and loose coupling is contradictory with each other

The coarser granularity of breaking down, the looser coupling

The finer granularity of breaking down, the higher cohesion

It reflects the ITA capability to take into account both high cohesion and loose coupling


Passion for beauty of software

Ugliness of software: hard to use, unreliable, carelessly structured, difficult to change

Beauty is faster and cheaper than ugliness, ugliness will slow you down and make your software expensive and brittle

Beauty of software comes from leadership, relevant expertise, effective communication, and healthy discipline; first of all, passion for beauty of software


Trade off

Given the many factors that influence an architecture, it is clear that the process of architecting involves making tradeoffs

2. Don’t provide feature

3. Provide feature by manual, but not by system

4. Provide feature by hard coding system

5. Provide feature with less friendly UI

Refactoring: improve the design of existing code


Leadership capability

The ITA should understand the delivery process, understand team member roles and responsibilities, ensures that all of the members of the team work in a coordinated manner to achieve conceptual integrity

process trap


Process trap

Process is just vehicle to help or force to think about the business and system, record the ideas after thinking, and effectively coordinate and communicate with each other

Document is the byproduct of thinking, don’t document for the documentation sake

Process can’t guarantee the delivery of excellent system even you comply with it strictly, don’t follow the process for the process sake


Module outline





Case study




Using the film industry as an analogy:

ITA is the director

PM is the producer

Consultant is the writer

ITS is the photographer, stuntman, makeup etc


ITA and PM’s responsibilities

One of the biggest obstacles to effective performance of the ITA is the lack of a clear division of responsibilities between the ITA and the PM:

ITA is responsible for the technical work, PM is responsible for the non technical direction of the team

PM is to unburden the ITA by handling certain non technical tasks, to control the team so that it conforms to the goals of the organization

It's useful for the ITA and PM to discuss their roles at the beginning of the project

PM ITA

Requirement, analysis

Design

Implementation

Unit testing

System testing

Estimate and schedule

Training

Hardware, service, supply

Management liaison

Hire, fire, OT, benefit

Customer liaison


Module outline





Case study



Case study: different results with ITA and without ITA

This is an actual and concise example from the China IBM.com project

Present how the ITA applies for consulting capability, abstract capability, hands-on capability

Show the different results with ITA and without ITA


Consulting: China IBM.com web pages


Abstracting: China IBM.com web page concept model

Footer

Header

Navigate Content

Through data collection, analysis, consulting with web page developer, querying IBM.com UI standard, summarized the China IBM.com web page concept model:

IBM.com web page consists of 4 part: header, footer, navigate, content

Hands-on: China IBM.com web page template

<%@ page contentType="text/html;charset=GBK"%><%@ include file="/include_new/IbmcomHttpPageHeader.jsp" %><ibmcomfw:pageBody pageName=“IBM.com模板页面">

<ibmcomfw:pageNavigate>

</ibmcomfw:pageNavigate>

<ibmcomfw:pageContent>

</ibmcomfw:pageContent>

</ibmcomfw:pageBody><%@ include file="/include_new/IbmcomPageFooter.jsp" %>

Header

Navigate

Content

Footer


What’s difference with ITA and without ITA

With ITA

Requirement

Analysis

Design

Implementation

Without ITA

Document

Document

Document

Implementation


Different implementation result with ITA and without ITA

With ITA Without ITA


Benefits with ITA

Bring order, flexibility, maintainability and extendibility to system

Improve the system capability to contain risk

Improve productivity in long term, but maybe impact schedule in short term

Provide tool, framework for others, but not just use tool, framework provided by others


Module outline





Case study



Recommended books for ITAAnalysis and design:

Gamma, Erich, et al. Design Patterns: Elements of Reusable Object Oriented Software, Addison-Wesley, 1995, ISBN: 0201633612

Ken Pugh. Prefactoring, O'Reilly, September 2005, ISBN: 0-596-00874-0

Brett D. McLaughlin, Gary Pollice, Dave West. Head First Object-Oriented Analysis and Design, O'Reilly, November 27, 2006, ISBN: 0596008678

Martin Fowler, David Rice, Matthew Foemmel, et al. Patterns of Enterprise Application Architecture, Addison-Wesley , November 05, 2002, ISBN: 0-321-12742-0

Robert C. Martin. Agile Software Development, Principles, Patterns, and Practices , Prentice Hall, Oct 25 2002, ISBN: 0135974445

Martin Fowler, et al. Refactoring: Improving the Design of Existing Code , Addison Wesley, July 8, 1999, ISBN: 0201485672

Requirement:

Karl E.Wiegers. software requirements, Microsoft Press, 26 February, 2003, ISBN: 0735618798

Alistair Cockburn. Writing Effective Use Cases , Addison-Wesley , 2000, ISBN: 0201702258

Steve Adolph, Paul Bramble, Alistair Cockburn, Andy Pols. Patterns for Effective Use Cases , Addison Wesley, 2002, ISBN: 9780201721843

Stephen Withall. Software Requirement Patterns, Microsoft Press , 2007, ISBN: 9780735623989

Software engineering:

Dan Pilone, Russ Miles. Head First Software Development, O’Reilly, 2008, ISBN: 0-596-52735-7

Brooks, Frederick P., Jr. The Mythical Man-Month, Addison Wesley, 1995, ISBN: 0-201-83595-9

Andrew Hunt David Thomas. The Pragmatic Programmer: From Journeyman to Master, Addison Wesley, October 13, 1999, ISBN: 0-201-61622-X

Mary Poppendieck, Tom Poppendieck. Lean Software Development: An Agile Toolkit, Addison Wesley, May 08, 2003, ISBN: 0-321-15078-3


Any questions?

What is IT Architect

Technology

Transcript of What is IT Architect