html5-img
1 / 15

Questions for discussion

Questions for discussion. Can architect descriptions help prospective users to visualise the solution in terms of meeting its requirements What is the relationship between architecture and requirements Can we used architecture to describe to help prospective users to visualise our solution

vadin
Télécharger la présentation

Questions for discussion

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IBM Confidential

  2. Questions for discussion • Can architect descriptions help prospective users to visualise the solution in terms of meeting its requirements • What is the relationship between architecture and requirements • Can we used architecture to describe to help prospective users to visualise our solution • How do top level reqs. Induce lower level reqs. In a loosely coupled architecture • Are there architecture lessons from Open Systems / Open Source that need to be applied more broadly? IBM Confidential

  3. Supply Chain of Requirements • Initial creator created then hands over • Next person splits that problem out to say multiple suppliers • Each supplier will interpret those requirements differently and provide possible alternative solutions to break down the problem • The issue is that we never loop back to validate the new requirements that are evolving versus the original requirements set IBM Confidential

  4. What is a system – the following are some of the terms we felt were included in the scope of a system • Hardware • Software • People • Procurement • Business • Suppliers IBM Confidential

  5. Captured discussion points • Two aspects to requirements • Functional & Non-Functional • Need to use both of these to work out what is technically feasible • ISO standards now say there is only functional requirements: some of which are quality requirements. E.g. Security, Availability ISO 9010, ISO 90126, Robert Grady • We need to take a broader view than Users this should be multiple stakeholders • E.g. call centre, the person at the end of the phone, etc • The people who want the solution are not IT people or IT literate (we want solutions described in business terms) • No requirement is completely independent of the architecture that is chosen • No requirement is made that was not perceived by the possible architecture IBM Confidential

  6. Captured discussion points • Makes much more sense to look at things structurally as you can point at things. Rather than behaviourally e.g. Use Cases • You need both. Health system Example but in different measures • Architecture is important when you want to describe the requirements • COTS are generally more successful as they refine the scope through the product • Two beliefs • Build requirements then architecture • Build them with the architecture – the challenge is having the right understanding of known tradeoffs, etc to make as you go along IBM Confidential

  7. Captured discussion points • Handbook of architectures • This could help procurers to understand the art of the possible • It will require a competence that could describe these architectures in a business language • What do we mean by a failed project • Example here is a system that team makes a solution work in the end • Due to the original requirements are changed • Proposition is that the requirement review is missed due to the supply chain • What do we mean by deployment • At initial stages the solution does not meet the initial requirements • The requirements evolve and the system does meet the end goal requirements • This is made harder due to the public sector procurement rules in that IBM Confidential

  8. Captured issues • Common challenge is that the people paying for the solution have different visualisation of requirement to the people building the solution • Arrows work at less technically aware people. UML relationships are formal methods. (visualisation) • If you go in with a set of architectures / requirements you may still get to a point that you do not have a solution you actually want “A little knowledge is a dangerous thing” • I don’t need a roving land vehilcle I require a telescope • When you have something that is tangible, air traffic control, etc it is much easier to assume that an Architecture is useful if its something that is fuzzy such as a data mining solution, it is not as useful as you can constrain the design IBM Confidential

  9. Captured Issues • To what level should the architecture be exposed to the client • Implicit understanding from requirements folk that clients understand architectures • Too much understanding of architecture will destroy innovation • Need to distinguish the architecture of a problem from the architecture of the solution • Should be able to articulate the problem first • Specifying the architecture can constrain innovation • Issue is not lets write another book, lets get our clients to read the books that have already been written IBM Confidential

  10. Open Systems / Source • Issue is of trust • If you only have interfaces you do not get the total trust • This can be gained through standards bodies • Can we build a bespoke solution using off the shelf bits but with the assumption that they will have to change their business / initial requirements • This has to be in a constrained domain like SAP, internet retailer, • It would be good to capture a Domain taxonomy / classes of system • E.g. Internet retail system • ERP • EAM • CRM • Resource management • Payment Systems • Credit checking systems • Financials systems (ledgers , accounts payable, receivable) • Systems to meet regulation – the more regulation you have & the more complexity you have. • This could go up to the generic domain such as data management systems, transaction systems IBM Confidential

  11. Next Steps • A number of possible next steps were discussed: • A conference to share case studies • A practical guidance handbook for understanding requirements • Sharing of ISO standards around requirements language • A conference for many clients on the subject of architecture to requirements • Pull together case studies / architectures • Invites include CTOs CIO Chief Architects across the industry • Starter set to include Grady • Practical guidance handbook for “So you are having an IT System” • Sharing of ISO standards for definition of functional requirements to be shared IBM Confidential

  12. Categories of requirements • Two aspects to requirements • Functional & Non-Functional • Need to use both of these to work out what is technically feasible • ISO standards now say there is only functional requirements: some of which are quality requirements. E.g. Security, Availability ISO 9010 • Business rules & time critical rules that you cannot break • But this still determines your architecture IBM Confidential

  13. Shopping book is a good idea, but we are along long away from that • If we cannot define standard architectures in a language can we describe standard questions • Architectural decisions & patterns could help here IBM Confidential

  14. ACTIONS • Liping Zhao to send everyone the ISO standard of requirements labelling • Peter Eeles to send ISO 90126, Robert Grady material IBM Confidential

  15. What type of requirements • Person who will get the machine • Accept instruction to move to a new location is not something I would like • But as an assembler we need to know that these things will work together. IBM Confidential

More Related