资源描述
Technical e-business Architecture Method,TEAM Practice Steps,The IBM Signature Selling Method and TeAMethod are based upon alignment with the customer buying process,Signature Selling Method:Outcomes,Sell Cycle Verifiable Outcomes Customer and IBM agreement to the value of a relationship. Customer-demonstrated interest in working with IBM. Customer-stated business need,buying vision and agreement to support IBM access to Power Sponsor. Customer Power Sponsor and IBM agreement to go forward with a preliminary solution. Customer Power Sponsors conditional approval of proposed solution. Customer and IBM sign a contract. Customer acknowledges the value of the IBM solution.,ldentified,Validated,Qualified,Proposed,Won,Completed,TEAM:Work Product Format,Title Purpose SIMethod work product enabled Description Creating the work product Sample work product,TEAM:Work product Dependency Diagram,TEAM:Task Format,Title Purpose SIMethod task enabled Description Associated work products/technique papers,Phase/Activity/Task(GSMethod Task)/Work Products(GSMethod Work Products),Plan Evaluate Customers Business Environment Define Business Context, Validate Business Issues and Goals(Define Business Context answers the question:“what are we doing on this project and why?” Helps ensure agreement to the project goals Identifies issues early on in the project Provides a basis for development of the architecturabas solution,SYSTEM CONTEXT DIAGRAM:,Identifies scope boundaries Defines interface requirements Helps identify potential interface solutions,USE CASE MODEL:,Provides functional requirements for development of your solution Provides a process for validating a proposed solution Helps in planning a PoC Prioritizes/categorizes system capabilities Helps define release strategy Identifies user and system interfaces Use Case Description helps describe(in text)the systems responsibilities.,NON-FUNCTIONAL REQUIREMENTS:,Documents critical requirements like performance, security, and availability that must be met by the proposed solution Helps validate the proposed solution Provides a basis for estimating the size and cost of the proposed system First sign of potential software product requirements,VIABILITY ASSESSMENT:,Helps you determine the probability of success for a proposed solution Highlights issues and risks early on, when they are more easily resolved,ARCHITECTURAL DECISIONS:,Provides your rationale for including IBM content in the solution Lets you position IBM content to customers within an architectural context Communicates the foundation for your choices to the implementors such as IGS,ARCHITECTURE OVERVIEW DIAGRAM:,Communicates the architecture solution“vision”to all parties Identifies the IBM and third-party elements of the proposed solution Provides input to follow-on design and implementation work This is where themagichappens Use several views depending on the audience,AVAILABLE ASSET LIST:,Helps you justify your choices to customers and other parties Helps you keep track of your findings and thought process when researching options Helps avoid an RFP May include assets found in other projects within the same customer,COMPONENT MODEL:,Helps document the solution components and their relationships Identifies the components needed on the Operational Model Helps validate a complex solution,OPERATIONAL MODEL:,Helps validate a solution by showing how non-functional requirements are satisfied Helps provide early cost and sizing estimates for the proposed solution Helps plan for the implementation of the first project or PoC,ARCHITECTURE BRIEF:,Helps you quickly identify products that fit the customers requirements Helps you identify product issues that may affect the project Helps you determine skill requirements that affect your recommendations for products or services,
展开阅读全文