- Scenario (Information from Contractor)
- Customer (IT Business Manager) engages a Contractor (Freelance Developer)
- Customer provides an XHTML template to the Contractor
- Customer specified that they wanted a scalable/open solution
- Contractor interpreted that performing the following is the only way to satisfy those conditions:
- Contractor codes the back-end using PHP/MySQL and integrates with the given front-end template using JavaScript/AJAX/jQuery
- Contractor deploys the website output incrementally for the Customer and constantly asked them to visit it and provided feedback, answer the Contractor's questions as to whether they were satisfied with the solution, and respond to implementation recommendations proposed by the Contractor, provide missing inputs (i.e. artwork, templates), and provide contact details of the Designer of the template.
- Contractor prepares a Process Flow Diagram (interaction between HTML, JS, PHP and DB)
- Customer accuses Contractor of providing "Random pieces of code"
- Customer never provides the missing inputs and contact details, and accuses the Contractor regarding their professionalism.
- Customer notifies the Contractor that they asked for, but did not receive an "architectural structured view", they claim that they used the code for a Demo to see what the code did, which caused them to come to the conclusion that the Contractor had "created random modules of code" rather than a "structured system" (after a year had gone by), and claimed that they were not confident that the Specification was understood and that the Contractor was able to "create a solution". Subsequent to this, the Customer refuses to engage in further talks with the Contractor.
- Contractor considers approaching the European Union Human Rights Court to protect other IT professionals from such Customers, but first requires an IT Audit of the Solution
- Issues & Questions (Questions from Luke Schoen to the Contractor)
- Is there an underlying Software Development Agreement (SDA) with a "Payment Terms" clause that was signed and executed by both parties?
- Given that the Customer specified that they wanted a "scalable" / "open" "solution", is there a "Baseline" Statement of Work clause or similar in the executed agreement. Is there an Appendix in the contract with a Schedule of agreed and timestamped "Addendums" (i.e. post-"Baseline" updates)?
- Are there clauses in the contract that set out the agreed Specifications, and associated Assumptions and Exclusions?
- Is there a Definitions clause that defines the agreed in-context interpretation of the words "architectural structured view", "structured system", "scalable", "open", "solution"? Or that refers to meanings described elsewhere (i.e. TOGAF Ch 3: Definitions)?
- Is there clause that specifies Legislation, Standards, and Guidelines that must be complied with (i.e. IEEE-Std-1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems) (i.e. TOGAF Ch 21: Enterprise Architecture Standards Information Base)?
- Did the Customer (Sponsor/IT governance function) provide a Statement of Work contract for the Enterprise Architecture that they intended for you to embark upon (i.e. TOGAF Ch 25: Architecture Contracts)?
- Did the Customer define a formal Architecture Compliance Review Process for reviewing your compliance progressively against the Enterprise Architecture (i.e. TOGAF Ch 24: Architecture Compliance)?
- Did the Customer define how they wished to approach Architectural Requirements Management (i.e. TOGAF Ch 15: Architecture Requirements Management)?
- Is there a "Requirements Definition" or a "Schedule of System Stakeholders & Concerns" in the Statement of Work to empower you (as the Solution Architect and Developer) to identify them and clarify their "Concerns", establish relevant "Viewpoints", and demonstrate that all requirements and concerns have been modularly addressed in development of the whole system solution by means of multiple "View" representations (Typical Stakeholders on Pages 14-15 of presentation IEEE Std 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems by Rich Hilliard. Also refer to Examples on Pages 20, 21, 23, and 25)?
- How were the expected Inputs and Outputs defined (i.e. TOGAF Ch 16: Input and Output Descriptions)?
- Did you establish what "Viewpoints" were necessary to be defined (i.e. Enterprise, Information, Computation, Engineering, Technology) (i.e. OASIS SOA Views and Viewpoints)? Is the link you provided representative of an Architecture Definition Document (i.e. see Example in TOGAF Ch 2: Core Architecture Concepts). Here is a link that explains how to Develop Architectural Views (TOGAF Ch 31: Developing Architecture Views)
- In terms of "open"-ness, did they provide you with a Multi-Vendor Open Systems Diagram, or at least explain the systems it would integrate with, so you could establish how to integrate a compliant solution appropriately (TOGAF (Why is it important?) )?
- In terms of "architecture" did you establish in the contract which types of architectures were required to be described (i.e. Business, Data/Information, Application/Systems, IT) (i.e. Enterprise Architecture and TOGAF 9 Overview by Winton Huang)
- In terms of "scalability", how did the Customer describe the baseline of the the Physical Application Component (Scalability characteristics) of their "requirements" and "concerns" (i.e. the current and forecast demands of the environment in which it operates) (i.e. TOGAF Ch 34: Content Metamodel)?
- Responses
- No written contract
- Solution provided by Contractor had worked previously
- Client-side Project Manager's skills considered ineffective by the Contractor and were more that of a Network Administrator
Note: This Case Study has been developed as an educational tool on Enterprise Architecture Standards. Inputs and opinions obtained are limited to that described in the Scenario, which has been reworded for ease of comprehension, but therefore may no longer be entirely true or correct.
Links
No comments:
Post a Comment