[1045] in I/T Delivery
Windows 2000 Domains & Servers: January 2003 Delivery Report
daemon@ATHENA.MIT.EDU (Kerem B Limon)
Mon Feb 10 11:51:44 2003
Message-Id: <5.1.1.6.2.20030210095624.04188448@po11.mit.edu>
Date: Mon, 10 Feb 2003 11:51:37 -0500
To: Delivery Process <delivery@mit.edu>
From: Kerem B Limon <kerem.limon@MIT.EDU>
Cc: Windows Delivery Team <windows-delivery-team@mit.edu>,
Windows Delivery advisory council <windows-delivery-advisory@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Project Name: Windows 2000 Domains & Servers Delivery Project
Project Leader: Kerem B. Limon
Report Date: February 7, 2003 (for January 2003)
Project Web site URL: http://web.mit.edu/windows-delivery/
Accomplishments in January:
- Working Group (core team, cf. Delivery Report for December 2002) and full
team continued to meet regularly after the break to work on various phases
of the project, focusing primarily on:
o finalizing DART process design and membership
o dealing with the shifting priorities in the Windows space as
circumstances change (more later)
o bringing ongoing Windows pilots to a reasonable close or holding status
where they can be used as "examples" or "working models" for the community
as part of the DART process
o community developed information gathering tools as part of a potential
DART toolkit
- Revised the DART process flowchart and finalized a top-level process map
with the identified dependencies remaining to be resolved (more later).
- (Working Group - core team) met with Dell & Microsoft representatives to
discuss a standing offer to participate in our long-term migration efforts
for DLCs. The focus of the discussions were to negotiate an exploratory
effort in which Dell & Microsoft would collaborate with MIT in the
migration of a few select departments to independent Windows domains (and
possibly IS win.mit.edu domain containers) by providing dedicated resources
and expertise through their consulting groups (Dell Professional Services
(DPS) and Microsoft Consulting Services (MCS)). One goal of this effort is
to help get some independent Windows domain pilots, as recommended by the
Discovery phase, off the ground. This is particularly so in the case of
groups involved with our work from early on and thus are familiar enough
with the context so as to be able to bypass a full-fledged design process
and have clear-cut needs for an independent domain. Secondarily, we see
this as an opportunity to be able to evaluate DPS and MCS as potential
partners for future referral through DART, for departments who may
wish/need to seek outside (i.e. non-DLC or non-IS) resources to implement
their designs and carry our their migrations.
- Generated new draft Web site designs for review by the Delivery team and
sponsors, and decided on one. Began migrating context from team
documentation, notes, announcements, etc. into this space to promptly
publicize to the community at large. One important decision made in this
space was to merge the team/project Web presence with that of the actual
documentation and information the Delivery process will generate under a
single portal. While the two segments will remain independently maintained
and organized, the goal is to provide a one-stop location for people
seeking to find out about the project itself, and at the same time be able
to see the current status of what is available and what is being worked on.
The documentation generated, being modular as such, can then be moved into
the appropriate Web space under Service and/or Support when the Delivery
work is completed, without much difficulty.
- (Project Leader) met with the sponsors regularly to discuss changing
priorities and the developments in the Windows space. Generated a
first-order, detailed technical description of Windows products and
services currently being offered by IS as requested, and began working on
abstracting from this a simpler, higher level summary of modular components
and how they fit together, dependencies, etc. in the Windows space.
- (Project Leader & WinAthena liaison) continued participating in WinAthena
Team meetings (as schedule allowed) and WinAthena Container Administrators
meetings regularly.
- Continued to keep key project team members tuned into the ongoing
Microsoft Premier Support Services (PSS) loop.
- (Project Leader) continued to meet with the Software Release Team (SWRT)
and Support HQ representatives in an ongoing effort to enhance the
arrangement of and the tools available to the various *partners
(ITPartners, MacPartners, WinPartners) groups. Our focus here is
specifically to contribute to the design and development of these resources
early on such that some of them can become part of our support (and perhaps
training) strategy later on in our project to avoid duplication of effort
and save IS resources.
Goals for February:
- Finalize DART membership, document final version of the process, secure
necessary outside commitments and announce the DART team publicly.
- Publicize the finalized Web site.
- Send out a community announcement and status update.
- Finalize negotiations with Dell & Microsoft consulting services, get
statement of work approved, and launch independent domain design pilots.
- Continue *much* closer communication with ongoing pilot Windows efforts
as well as DLCs that have already moved/are interested in/constrained to
urgently moving to Windows 2000 Domain & Server platforms. Collaborate with
Dell & Microsoft as specified above.
- (Quickly) design and get consensus around a simple yet clear process for
handling requests for container in the IS win.mit.edu domain, processing,
routing, and tracking them, and in doing so, involving and informing all
the relevant parties. Most likely implement a mechanism that involves
CaseTracker.
- Finalize (1) the accessible description of WinAthena and its components,
in collaboration with the WinAthena Team; and (2) a technical version
geared towards network/system administrators that help define the
boundaries of IS offerings in the Windows arena; our goal here is to assist
customers (and DART) in helping make the choice--by clearly annunciating
what's available and how it best works/serves them.
- Continue, though in the background, our survey/inventory of academic &
administrative departments and research labs & centers to gauge upcoming
scalability/migration needs; collaborate with the Academic Computing
practice efforts in the same direction. Implement this information in a
secure, internal team database.
Next Community Milestone:
- Announcement of the finalized (initial) Design Assistance & Review Team
(DART), including complementary documentation to WinAthena to offer a
simple and accurate gateway to those interested in Windows server & domain
deployments at MIT. (targeted for February)
Issues:
- We are behind in announcing DART, but a lot has changed since December
and this most crucial part of the entire process appears to be far more
complicated then we initially estimated.
That said, part of the complication arises from a number of emerging issues
that I elaborate on in the following sub-bullets:
o We need to determine conclusively what the announcement of a design
assistance & review resource will imply when the remainder of the process
for Windows 2000 domain work is yet to be completed; i.e., with the
migration/deployment resources and documentation, support options,
processes, resources, best practices, security recommendations, etc. still
in development, what does it mean for a DLC to go through the DART design
phase? When the DART negotiations are completed and a basic design is
produced as a result, where does the DLC client turn to at this stage, with
the rest of the Delivery stages as yet in construction? What kind of
"statements of understanding" and "responsibilities and commitments"
documents and agreements can we arrive at through DART without the
components through which such understandings, responsibilities, and
commitments will be enacted yet in place? At the same time, we cannot
possibly hold off until *every component* is in place before we make a DART
announcement. In other words, what sense does it make to prescribe the
patient when the pharmacy or the clinic isn't built yet? And if so, what do
we do with critical patients in the meanwhile?
o The team at large feels that the priorities behind the project/work have
changed and are in fact quite different (and wider) than what we set forth
with in October 2002. Mostly, there is concern that this team was initially
put together to develop processes and mechanisms, and *not* actual
deployments or migrations with the exception of select, essential
proof-of-concept pilots that were to _feed in_ to the Delivery team, but
were to be run in parallel and not to be authoritatively overseen by us.
Unfortunately, unforeseen delays in the pilots, lack of communication, and
our hesitation to devote resources to actually do this kind of oversight
(as originally asked) has cost us in delays and the current lack of those
completed "proofs of concept". As a result, there is a general feeling that
we are now being (indirectly) asked/forced to devote overhead to seeing to
the successful completion or to bringing to a hold at some reasonable stage
these pilot projects such that we can actually use them as examples for
both our own process design and as possible starting points, guidelines,
selling points to the DLC community. This is undoubtedly going to take away
from our core process work, as it already has, and is likely to continue to
delay us.
o Relating to the previous two sub-bullet points, are our efforts in
scrambling to get some pilots off the ground and at the same time trying to
keep other DLCs holding for us to finish our work unrealistic? What about
the continuous "adjustments" and "accommodations" we make in the form of
additional pilots for those DLCs that are ready to move along and will do
without us if we do not interject? Is undercutting consistency and
standardization of a formal design assistance/review process (and its very
design and development itself) continually through these interrupt driven
requests to "keep everyone in line" worth the effort, or should we accept
that some will "sneak through the fishnet"? Can we simply maintain contact
with these early adopters and provide them with the minimal info needed to
make sure they do not run into problems and/or affect other customers'
service, and focus on our core work?
o The team at large feels that there isn't enough communication occurring
between the various related IS groups in the Windows space, as well as
between some of the IS processes. The vision this team had (and continues
to have) in October 2002, does not necessarily match that of the various
sponsors (quite expected), and it is proving challenging bringing together
the various visions or perspectives (also expected) from outside this team
with that of the team itself. This point is not being made as much to
complain as it is to illustrate the challenge of trying to define what IS'
"Windows policies and directions" are likely to be, and how integral and
significant a role that definition will play in the outcome of this project
and vice versa. While the team feels that there is a general direction and
a committed "push" to move forward, the exact direction of that push is as
yet, not unified or clear.
o Related to that last sub-bullet point, the team is also concerned that
some of the design recommendations, resolutions to issues, configurations
finalized during the Discovery process and reviewed and approved by ITAG
are being questioned and critiqued again. While it is understandable that
design choices remain open to review as the circumstances change and that
unified consensus is hard to obtain, the team feels that some matters
should be conclusively resolved and the outcomes dictated by such decisions
be enacted without having to re-cycle the process over and over. This is a
significant concern in the areas where internal (to IS) and external
dependencies exist.
o One example of communication problems, quoted verbatim below from the
previous report, is the lack of a process to field, handle, route, and most
importantly *track* container requests in the win.mit.edu domain (cf. next
bullet for more detail). We expect a similar snafu to occur in the request
of DNS subdomains, as recommended by the Discovery phase, for the
implementation of IS-independent Windows 2000 domains unless we move
quickly to rectify both problems.
- (remaining valid verbatim, in fact, from last month, quoted for
posterity) The status of the parallel Windows pilot projects, such as a
number of WinAthena implementations, etc. are critical to our work as case
studies and more so as real world successes and working implementation to
our customers. While it is not within the scope of this project to "manage"
these individual efforts per se, the significance and need for their
outcomes requires an increased oversight on them on our part.
- (remaining valid verbatim, in fact from last month) While we have draft
processes in place to deal (differently, by design) with academic and
administrative requests for DLC containers within the WinAthena win.mit.edu
domain environment, we need to move ahead in formalizing these better or
establishing stricter response criteria and times. This process needs
further (and immediate) development, as some customers have begun to
express disappointment stemming from disconnects. The team will continue to
work with WinAthena and the sponsors to deal with this issue.
Key Learnings:
- "Parallel-coupled projects do not necessarily run on par, but they do
fail that way" : We need to spend more overhead and oversight on the
parallel pilots that we count on for input. While it may have seemed
generally comforting to be told that we were not primarily responsible for
these efforts and that we could count on them as being there when
necessary, Murphy's Law comes true yet again--if you need something, you
need to go get it yourself. As such, we will spend more time following up
and seeing to the completion of these pilots whose results we desperately
need for our work. It will take from our core focus, but unfortunately, we
have not other choice.
- "It may seem there is no such thing as a free lunch; but don't refuse
when offered the real thing just because of the saying" : We need to
collaborate more openly with partner institutions and industry in moving
some of our larger projects along, such as this one, especially when they
are willing to make some resources available just to get our attention.
With clever and honest discussion, it is possible to have our cake and eat
it, too. For instance, for running some of the pilots, we can use, with
sufficient oversight and exchange of info, resources from an industry
partner like Dell or Microsoft and both benefit from them in the short term
and also hopefully (if all goes well) build a working relationship in the
long term in this arena.
- "You can't win 'em all" : We need to pick our battles and focus on those
fronts to win the War that we can. It's becoming highly unrealistic that we
will be able to hold off each DLC until July 2003 to migrate to Windows
2000. It is even more unrealistic to assume that we could do so and product
a consistent, standardized design process, best practices, associated
services and support resources, and a future-looking technology watch
effort at the same time. It is the time to give whatever is necessary to
those who cannot wait to move, and keep watch only to ensure they do not
run into trouble or shoot themselves in the foot, and learn from their
choices and mistakes.
- "Don't assume people will naturally share information in a centralized
infrastructure" : Even hundreds of Athena mailing lists and NexTel Direct
Connect sets cannot make that happen. We are finding ourselves increasingly
becoming the hub of information and/or clearinghouse for Windows
information, which is a positive development for the team, yet a negative
result for our Windows work overall. Since each feed into this hub is
facing a different direction and has a different perspective, having all of
the information does not necessarily mean everyone facing in the same
direction (more or less). There is a need to be doing far more central
_and_ more importantly, peer-to-peer networking here.
- "Always get it in writing" : ("But we did.")We need to be firm about some
of the commitments/agreements made around design decisions brought up prior
to the Delivery process in various IS (and wider) decision making venues.
Now is not the time to reinvent the wheel, but to get it rolling.
Team Dynamics:
- Excellent despite rising issues and discomfort of delay-causing problems.
Good rapport and interest continues.
Additional Comments:
