60 likes | 218 Views
Experience with COTS-Based Systems (CBS) Product Line Architectures. Don Andres 7 February 2001 703.803.5109. Project Context - C 2 Product Line. Project purpose was to develop COTS-based Command and Control Product Line Architecture Address wide range of DoD mission requirements
E N D
Experience with COTS-Based Systems (CBS) Product Line Architectures Don Andres 7 February 2001 703.803.5109
Project Context - C2 Product Line • Project purpose was to develop COTS-based Command and Control Product Line Architecture • Address wide range of DoD mission requirements • Support Air, Missile, Space domains • Support Theater and Strategic missions • Driving Factors • Need to interoperate with existing systems, majority of which were developed as standalone systems • Incorporate commercial technology while still adhering to Government standards (time gap) • Resultant systems need to be highly reliable with near-real-time performance
Vendor/Product Experience • Oracle - database, web server, web portal, development tools • Iona, BEA - middleware • Toplink - Object to Relational mapping for database objects • Tivoli, OpenView, CA - Network Management, Product Distribution, Inventory • Remedy - Network Problem Reporting • Government - DII COE (operating system, patches plus applications), Global Command and Control System (GCCS) • Rational - Rose, ClearCase, RequisitePro, ClearQuest, Dashboard, TestMate • Symantec - Visual Café (Development and debug tools) • Other Pieces (NT, Unix, Java Virtual Machine, PKI certificates) • Languages • C++, Java (New) • C, Fortran, Ada (Legacy)
Challenges • System characteristics and performance parameters different, in many cases, than those for which the products were designed • Design/tailoring/negotiating some requirements • Government standards specifications, in many cases, lagged commercial state • e.g., Operating system levels/patches • e.g., versions of Java Virtual Machines • note: this was also an issue between Vendors/Products
Lessons Learned • “Teaming”, or entering into a partnership with key vendor was critical to success • Dramatically reduced time-to-market • Eases the learning curve • Hands-on evaluation is critical • Substantiate that requirements (esp. performance can be met) • Understand the difference between “standards compliant” versus “based on standards” … may be synonym for proprietary (partial) implementation of a standard • Integration is not easy • Engineering rigor is still required • Not the schedule reduction silver bullet, can be very time consuming • Vendor support should be heavily weighted in evaluation criteria • More important than initial investment cost • Probably equal to capability • Built-in diagnostic/performance capability is important
Critical Success Factors • COTS-based systems still need to be managed and maintained • Patches, version updates need to be incorporated in a timely manner • Resource sizing (CPU, memory, disk) need to take into account all of the products being used (esp. if there is the potential for concurrent execution) • The concept of peaceful co-existence is still, in many cases, a myth • Define benchmarks based on your own business rules and system characteristics • Integrated (those where several vendors products are involved) benchmarks are hard to analyze • Performance and resource utilization estimates are not always linear and many times do not transfer from business model to business model