SCIF 2.0 Spec

1.2 Vision


Project Vision Statement:

“Empower developers at any level of experience to easily develop products that automate or integrate with the data, workflow, or user interfaces utilized by the System Center product line”

Breaking down the vision statement into its individual parts yields a view of the principles of the project:
Empower Empower – as opposed to enable – means that we provide the information and tools necessary (like an SDK/API), as well as go beyond to provide real world samples, rich documentation, snippets, components, templates, and more.
developers at any level of experience Our target persona includes those we would call developers but with experience levels ranging from “hacker” (IT admin) to seasoned veteran. We will assume familiarity (but not expertise) with PowerShell, C#, VBScript, and tools like Visual Studio.
to easily develop products While a PowerShell-based architecture enables use in many forms and using small components of SCIF as an IT admin would, we will be focusing on users developing or integrating 3rd-party products
that automate or integrate with the data, workflow, or user interfaces This means that existing features controllable through UI should be exposed through the PowerShell interface, and that all data and processes can be automated this way. It also implies that the UI is fully extensible.
utilized by the System Center product line Even if the different products in System Center utilize different object models, architectures, user interfaces, and command structures, SCIF will allow for an easy way to communicate with all of them.

1.2.1 Delivering the Vision


In order to fulfill the goals of the above vision statement, SCIF 2.0 should have the following elements:

Code Library:
  • UI components, controls, and templates that can be plugged in to Visual Studio easily, providing quick ramp-up for developers creating integrations.
  • PowerShell cmdlets and scripts that allow for quick linkage to existing (and future) System Center-provided cmdlets and scripts, extending functionality, adding utility, or easing integration with System Center products.
  • Large base of utility code to help work with related products (e.g. WAIK or WinPE) or provide useful functionality for speeding up development.
Guidance and Documentation:
  • Prescriptive guidance on UI, data and workflow development best practices, sample code and user interface modules, and preferred (or required) configurations.
  • Best practices for development and testing of the framework and extension code
  • Real-world usage documentation, walkthroughs, and sample applications

1.2.2 Value Proposition


The Framework lightens the load for developers writing integrations not only by helping them integrate, but by taking care of a lot of the underlying core code they would have to write anyway. By utilizing the Framework, development cycles are shortened and frustration is reduced. One of the purposes of the Framework is to also help developers who want to integrate with multiple System Center products. Today, each new integration results in a large learning curve and effort in understanding the processes, objects, APIs and requirements of the new product. With the Framework, developers will be able to transition to new products in the System Center product line with a much lower learning curve and retain much of their existing code.

Part of the Framework is also the establishment of best practices, common techniques for testing and logging, and for development in general. A huge benefit to the developer and to the customer is the instilling of these best practices into new projects, resulting in lower development and testing costs, as well as easier implementation and troubleshooting for the customer.

1.2.3 SCIF’s Guiding Principles


In the process of developing SCIF 2.0 and ongoing releases, we should adhere to the following core principles:
  • Leverage existing knowledge and work as much as possible. Don’t re-invent the wheel, share knowledge as much as possible, and utilize existing product extensibilities, product features, public tools, code, and other information however possible as it benefits the project. Look for ways to make public internal testing code and processes that are not IP-restricted.
  • Use rapid development methods.
    • Early prototypes focus on usability and allow for quick feedback on product direction because users can get an idea how they might use something.
    • Small, self-contained components allow for rapid development of new functionality without impacting existing code.
    • Lots of iterative releases with increasing functionality allow for early testing and feedback and require fewer formal beta programs and processes.
  • Develop for testability. All code should include unit tests. This not only helps ensure good coding practices, it helps ensure quality products, defines good testing practices for partners, and lets end users do testing as well.
  • Develop for extensibility. Assume that every part of SCIF may need to be modified by an end developer to suit their own needs, dialogs modified, workflows changed. With that in mind, development of SCIF components will not be closed and single-purpose and much attention will be given to how features will apply to multiple partners instead of adding functionality that benefits only one.
  • Release it to the world. All interim code drops are published to the Microsoft Team Foundation Server on the Microsoft Extranet. Everything in a release-level state (except vendor-specific code) is published to CodePlex. This allows direct integration with Visual Studio in a formal change management process, and allows for secure partner-only access to the source during development. CodePlex also provides for bug tracking, discussions, wiki-like web documentation, and more.

Last edited Aug 28, 2009 at 5:13 PM by rhearn, version 2

Comments

No comments yet.