what is it architect
TRANSCRIPT
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
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
3IBM Confidential © IBM Corporation 2008 All Rights Reserved
Misunderstanding to 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
4IBM 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
5IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
6IBM 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
7IBM Confidential © IBM Corporation 2008 All Rights Reserved
Fundamental capability of ITA
Consulting capability
Abstracting capability
Hands-on capability
Leadership capability
8IBM Confidential © IBM Corporation 2008 All Rights Reserved
Consulting capability
Requirement trap
What is requirement
What is stakeholder
9IBM Confidential © IBM Corporation 2008 All Rights Reserved
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?
10IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
11IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
12IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
13IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
14IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
15IBM Confidential © IBM Corporation 2008 All Rights Reserved
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!
16IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
17IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
18IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
19IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
20IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
21IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
22IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
23IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
24IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
25IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
26IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
27IBM 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
28IBM Confidential © IBM Corporation 2008 All Rights Reserved
Relationship with other profession
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
29IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
30IBM 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
31IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
32IBM Confidential © IBM Corporation 2008 All Rights Reserved
Consulting: China IBM.com web pages
33IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
34IBM Confidential © IBM Corporation 2008 All Rights Reserved
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><!--navigate [start]-->
<!--navigate [end]--></ibmcomfw:pageNavigate>
<ibmcomfw:pageContent><!--content [start]-->
<!--content [end]--></ibmcomfw:pageContent>
</ibmcomfw:pageBody><%@ include file="/include_new/IbmcomPageFooter.jsp" %>
Header
Navigate
Content
Footer
35IBM Confidential © IBM Corporation 2008 All Rights Reserved
What’s difference with ITA and without ITA
With ITA
Requirement
Analysis
Design
Implementation
Without ITA
Document
Document
Document
Implementation
36IBM Confidential © IBM Corporation 2008 All Rights Reserved
Different implementation result with ITA and without ITA
With ITA Without ITA
37IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
38IBM 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
39IBM Confidential © IBM Corporation 2008 All Rights Reserved
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
40IBM Confidential © IBM Corporation 2008 All Rights Reserved
Any questions?