Decentralized Development Teams
One of the growing development models
is the decentralized development team-based model, where IT provides a
centralized platform for the individual features, and departments or
decentralized development teams are responsible for (or in charge of)
individual features introduced for end users. These kinds of models are
great and flexible as long as the platform and environment are
carefully managed.
If the decentralized development teams require
only small customizations (such as branding changes), Apps and
sandboxed solutions in SharePoint 2013 provide an extremely flexible
platform to introduce changes and customization at the site-collection
level.
By providing a centralized IT-driven platform,
organizations and departments can take full advantage of the
flexibility of the platform. IT may also provide centralized services
to be available to decentralized development team releases, such as
fully trusted proxies for sandboxed solutions if there are requirements
to access some secured resources (which normally are not available from
the sandboxed solution code). Additionally, the apps model caters to
many new scenarios that were previously only accomplished using the
sandboxed model. Apps can be developed by the decentralized IT team and
submitted to the central IT team for deployment and inclusion on the
internal app Corporate Catalog.
Offshore Teams
If offshore models are utilized
properly, they can provide significant cost-savings in the development
stage. Often, however, organizations do not completely understand the
implications and what is required to use an offshore team.
For example, what methodology is suitable, what
level of technical specifications are required, what onshore and
offshore resources are required, what subtle cultural issues must be
understood, QA, onsite development leadership, offsite project
management, and planning and guidance for the customizations to be
implemented all must be considered.
Efficiently utilizing offshore development teams
and enabling individual features to be developed unfortunately tends to
require a waterfall-based approach, where a great deal of upfront
planning, thinking, designing, and documenting is required. There must
be little to no ambiguity in any documentation. Your user experience
and portal brand design must be completed earlier on in the process to
enable offshore developers to avoid delays and ambiguity during the
development.
For example, this means good documentation of any
platform-level services and details concerning individual styling of
the customizations (such as web parts). If roles and responsibilities
are defined properly, and there’s constant follow-up on the
customizations, offshore development can be extremely cost-efficient.
It requires extremely good project management and QA on the onshore end
to ensure that features work is specified in the documentation.
Other considerations for offshore development are
the customization ownership and how the source code is secured. If
development occurs both onshore and offshore, access to the same
centralized source code system must be provided. Figure 3
shows one model of having development synchronized between onshore and
offshore teams. Note the following in reference to the figure:
- The onshore development team uses remote connections to access centrally deployed development environments.
- A centralized virtualization host is used for development and QA environments.
- Individual development environments are included.
- A source code system (such as Team Foundation Server) is included.
- A virtual private network (VPN) or other remote connection port provides access to corporate resources from external networks.
- Offshore developers have their own development environments connecting to Team Foundation Server from Visual Studio.
Optionally, you could also provide individual
development environments for the offshore team, which would also be
hosted in the centralized virtualization host. This could be possible
as long as the offshore team could access the corporate network.
In this kind of model, the integration
point of the onshore and offshore customization is the source code
system from where actual builds can be then created.
