Department Of Defense SharePoint Architecture Guide (DSAG) Part 1 – Introduction And DIEA

I always wanted to put together SharePoint defense industry documentation because of 90% of my career being contracted with the Air Force but never found the time. Oddly enough, I did when I went private sector and only did part-time side federal contracts though :-)

The SharePoint 2010 Department of Defense Architecture Guide is an effort to minimize the friction of a SharePoint deployment into a DoD owned entity. While the focal point of the document is targeted to SharePoint 2010, the larger target is building collaborative tooling in the federal defense industry, and thus has broader applicability.

This compiled, preliminary effort focuses on structuring the fundamental standards required when constructing SharePoint environments within the defense industry. There are innate difficulties when putting together such documentation. The ostensibly more static federal computing infrastructure assimilating dynamic platforms such as SharePoint is a invariable struggle for those that wish to stay on the bleeding edge within a federal environment. I believe this is because of two main reasons:

1) Investment Guidance – Presently for a DoD owned entity (i.e. an entity that while potentially being under another entity is autonomous enough that they have the capability to fuel single, enterprise projects) understanding the investment and return has no baseline standardization, even for those more esoteric, abstruse benefits. This complicates the decision making process since interim forecasting becomes impossible, making it complex to hash out requirements and activities.

2) Lack Of Context – The implementation process of a SharePoint solution into a federal environment is commonly not parallel to those within the healthcare industry. Most federal solutions require a pre-existing context in which to assimilate SharePoint into. Furthermore, this context is progressively more complicated because it involves high-level consideration for concepts like implementation rules to more low-level considerations like constraints.

In order to solve these as well as other conundrums, there has to be baseline documentation established that does numerous things. Preferably this should allow a description of federal SharePoint resources, how they can be operated and managed within the context of a DoD entity, allowing contemporary solutions to be implemented while still ensuring the needs of the DoD are met. Ideally, this should cultivate more interoperable SharePoint environments that not only enable collaboration within a unit or with unit and parent entity, but rather within a branch and even between branches. Since information is a strategic asset, in order to make the most conversant tactical decisions it is obligatory to institute these collaborative defense semantics, this should facilitate better data sharing.

To do this, several of the foundation DoD concepts are going to be introduced and integrated within the terms of building collaborative tooling, in turn this should allow the exposure of the common foundation attributes that can extend over various deployments. Not only will this fortify the particular entity that is deploying SharePoint, but should also allow better collaboration to be cultivated between mission partners. This means consuming DoD implementation standards and weaving it with SharePoint solution building guidance taking into account current policies, directives, visions, and strategies (i.e. NetOps Strategic Vision). The most important of these that are going to be taken into consideration is Defense Information Enterprise Architecture (DIEA) 1.0. This type of foundation is one that offers support. At the same time though it is able to radically augment the transporting speed for that information to net centric operations (competitive war fighting advantage through the robust networking of well informed geographically dispersed forces) for the DoD. This allows them to be able to more easily identify barriers that they have to permeate.

With the information available through the Defense Information Enterprise (the DoD information resources, assets, and processes required to achieve an information advantage and share information across the Department of Defense and with mission partners), everything is available for review. This includes fundamental information, resources including assets, and the ability for an array of information to be shared through communications that this entity has with other layers of the department. There are standards in place to assist with the various types of operations on the management level. This allows the mission of all the fundamentals to successfully be sent throughout the department.

There are many different components that make up the overall portfolio for the DoD. When net centricity is initiated there is still the ability to continue being in compliance with the investments made by the IT department, even when considering collaborative tooling such as SharePoint. Everything that is part of the policies and procedures for management and guidance are included here. This gives the full range of action to be carried out through the use of this type of information architecture.
The DoD has such a program so that they are able to continue offering excellence in the area of IT. They have been very commanding in the area of developing standards including the Universal Core (UCore) XML-based data exchange standard and messaging framework. This is facilitated through Net Centric Core Enterprise Services known as NCES.

The DoD IT allows benefits from the use of shared commuting and communications. They have an infrastructure that works with the Global Information Grid (GIG). The GIG is The GIG includes any DoD system, equipment, software, or service that transmits, stores, or processes DoD information, and any other associated services necessary to achieve information superiority. The DoD also has stand alone information that can be embedded and that is self-contained. That type of information won’t be accessible through the enterprise network. One of their focuses is on creating policies and guidelines is it offers an opportunity for common goals to be reached. The ability to make important decisions based on what is going on with the net centric operation is very important. This makes it a valuable investment and also opens up ample supplementary opportunities.

With the DIEA there is unity for the various concepts found in the net centric strategies. This allows for common goals and policies to be part of the overall solution, including the acceleration of collaborative tooling deployment. The vision that the DoD has is to be able to offer a united system that all can benefit from. This will offer them many advantages that they can share with their partner groups and mission partners.

These advantages include offering an environment where sharing can take place. The data information will be visible as well as easily manageable to those that need it. Plus, everything will be austere to understand and only accessed through a trusted environment with apposite security measures in place. The network will be protected with an infrastructure that makes it possible for the operations to offer both dynamic and interoperable levels of communications. A variety of capabilities for commuting will be offered so that all of the tasks can be completed within that infrastructure.

Through the DIEA there is the ability to add more content to any policies that are already in place. The goal is to make sure that adequate guidance is in place within that framework for the DoD to function at a very high level. There are many rules, principles, and constraints that allow them to only take part in the very best of practices. This won’t be limited by the components of the program.

It is all going to abide by the compliance measures that have to be in place with the net centric vision. The collaborative efforts will be successful too due to the way in which information sharing is offered. It is important to understand that the current revision, Defense Information Enterprise Architecture 1.0, won’t be replacing any of the underlying policies that are already in place. The basic framework is going to continue as it already is.

However, the main benefit of this program is that it allows all of the different areas of the department to be tied together. They can follow the same types of framework to get addition guidance but to also stay within the set policies. This is going to offer more power to those that have to make decisions regarding the DoD and the components found within the portfolio.

This program is going to have a solid impact on the way in which decisions are made for the DoD. The rules will be linked to policies and standards that are part of the overall model. DIEA 1.0 allows well informed communications on important issues to be discussed. As a result it will also continue to make a stronger net centric environment for the Department of Defense. There is a vision they have in place for the future which should materialize in the next 3 5 years. With this in mind the Defense Information Enterprise Architecture will be seen as a tool by the Department of Defense. They will use it to help them identify objective that they will proceed to attempt to implement.At the same time there will be many components in place that may align the various programs of the system in regards to the vision for the entire enterprise and the use of net centrics. All of this is going to further continue to push forward the quality and benefits from the net centric environment that has been created.

The primary purpose of the enterprise architecture structure is to make sure everyone has the right information for guidance and to help them make decisions. Taken into the context of SharePoint, this means consistent deployment types and usage. Granted, this is chiefly talking about those that have a responsibility for IT, however, there is no limit to the ways in which this can be a benefit behind the scenes.

Next >> Department Of Defense SharePoint Architecture Guide (DSAG) Part 2 Accountability, EL Scope, And DIEA Customers


10 Steps for A Military SharePoint Contract

Recently a friend of mine won a substantial SharePoint military contract which I contributed to the RFP for since I owed him a favor (your welcome Kirk for my entire weekend). Although he has been doing SharePoint since it was Tahoe, he had on no account held a military contract, and was wondering about some pointers that he could take in that would facilitate reduced resistance, and increased applicability while engaging on the SharePoint project. As a result I started writing a personal email to him regarding some concepts since I just moved back into the private sector so felt equipped to, which hurriedly I could see as being a constructive post so determined to put it out there for the community.

Now this is all subjective, and might not translate to all military SharePoint contracts, so take it with a grain of salt. Though I think that bulk of the points are generalized enough that it should at least provide reasonable applicability for a preponderance of military contracts, matters such as these should be looked with gargantuan scrutiny.

Military Personnel Cause More Friction Than Private Markets

This really took me a while to get used to in view of the fact that for an assortment of private SharePoint projects it can be recurrent that people are in reality eager for a SharePoint deployment. Because of the way indirect clout and influence is shared within an orthodox military structure, and while there certainly is a defined chain of command, the defined rigidity does not make it an absolute. There might be a GS 9 through 11 that has been entrenched in a unit waiting on their pension, and they are a hard sell because they have been doing things a particular way for nearly 20 years. It has worked thus far so why change it now? And while on paper the persons ranking might not be directly impressive, that person’s relationships should make you look at them like they are a SES 2 as far as you are concerned. More often than not, you can gauge the assimilation of your deployment by measuring the adaptation of the product by such people, not by the early adopters that are clearly biting at the chomp in order to leverage SharePoint. Understanding these unspoken and undocumented relationships is huge!

It is important to realize that there is a huge gap between the private sector and the military segment in this regard. In the military, you would actually think that rank is king and that is the end of it. However it is customary that relationships habitually will trump rank. Furthermore, in the military, product use can, and more often than not, will be forced by a commander if you don’t play the implementation role just right. While this seems like it would be a benefit, you will quickly find out that it is the quite opposite. The old mantra You can catch more flies with honey than with vinegar goes right out the window, and now you are not the most favorite person in your unit since you are forcing people to change the way they do their jobs. Not only is this bad for the current state of your contract and your user audience, wait until the contract is up for rebid and those identical people are solicited for feedback during the proposal lobbying.

You Are Not A Civil Service Employee. You Are A Contractor

Don’t portray yourself as being a civil service employee regardless of where you are, it is a terrible habit to get into it and can be misconstrued as offensive to civilians. Most civilians have influential reasons for being a civilian otherwise they WOULD be contractors. The line between a civilian and a contractor is NOT fine, nor should it be or ever considered to be. You don’t walk into a meeting at a private sector client and claim that you work directly for the company in some position that would clearly only exist as an FTE at a private sector firm, don’t do it in a military environment.

FFS Don’t Piss Of IA

As far as you should be concerned, IA is trump. Not only should you not cause problems with them, making a good friend in IA will span your bases and contracts. I have known my same IA contact for nearly 5 years now, and even though he is staffed permanently at a different base I will most likely never work at again, the information he gives me regarding any of my current and future contracts regardless of station is nothing less than priceless. Just don’t do things that knowingly are going to make them upset, like putting a NIPR and SIPR box within the physical proximity limits of each other. They will rip your head off, and then you are on their radar and you will get hit on each audit. It’s kind of like the IRS in that sense I suppose.

Hiring A Generic Project Manager Will Go Over Like A Fart In Church

If you are responsible for staffing, do not under any circumstances hire a generic project manager for a military SharePoint contract. A project manager in a military environment is a specialized position since they have to understand the inner working of the military, this type of knowledge is disseminated through experience and not through book smarts or nonspecific PM knowledge. While a generic PM might understand the fundamental ranking and command hierarchy concepts, they will have no clue about how the military cogs make the overall federal machine work. Unless you want to send a lamb to the slaughter, just avoid it and shell out the money for a PM either with direct military background or previous federal work history (state governments generally do not count). Going back to the above point about acclimation of product, the PM will heavily be responsible for facilitating the rely of operational information that will affect the whole project. When they get the aggregate picture along with the intricate unit workings, their contributions are unmistakably noticeable and will cause the project to run much smoother.

Don’t DARE Tell A Commander How To Run His Unit

I love it when I am in a meeting and I see someone do this. A commander didn’t get to his position because he took shit on a daily basis from contractors telling him how to do things; they are in a leadership position because they are leaders and were noticed as such. They know their unit; otherwise they wouldn’t be in command of it. Don’t try to tailor a unit to SharePoint, simply give a commander options, and believe me, he will tell you exactly how he wants SharePoint to run in his unit. Trying to tailor a process to a product is poor form anyways; a military environment is unquestionably no exception. The best mantra when working with a commander is take ever should you were about to say and switch it with a could. There are many neat portions of SharePoint that could potentially solve critical business issues; they just need to be presented delicately and with tact.

What The…Different Commander, Different Day

It is pretty recurrent that command changes ensue, at least it was in the Air Force it is habitual. Don’t let it dishearten you; unless it results in the project getting canned then I would be frustrated as well. Restructuring is incomparably common in the military because the pronouncement can come from so many directions and sources, and while some are based on timely rotations, others are to optimize the workings of the unit(s) (such as unit merges, etc.). If you substitute commanders, you must approach the new commander and show him the value in your work instantaneously. The same reasons that the old commander firstly solicited you as a contractor for must be presented to the new commander so that he can see the significance in your work since he will be unacquainted with preceding efforts. If it is not immediate, manufacture a practical case study because it is worth the time. Otherwise, there is regularly a budgetary review process as one of the first things on a new commanders list, and he/she won’t even know why that money is going to a particular project.

Use That One Guy That Has Been On A Military Contract

I can’t emphasis this enough, on most military SharePoint projects this is generally one person on the team that has already done an enterprise SharePoint deployment in a federal environment. Same branch? Tremendous! Different Branch? Not as great, notwithstanding still pretty damn good. And it might not even be the person that is judged to be the most indispensable personnel on your team. Their insight into the pre-workings of a military structure you will discover to repeatedly save your ass again and again. Even when those concepts aren’t related to your SharePoint deployment and are just insights into significant military processes.

Acronyms Are Better Than No Acronyms

There are so many acronyms. There are acronyms for things that shouldn’t even be acronyms, but because it is an unspoken tradition to turn any three letter denotation into an acronym, you really have to get used to it. And seriously, don’t bother writing them down since there will be repetition in the acronyms that are used. You will end up using the same acronym a lot, but based on the context, it will have severely dissimilar meanings. This must be taken into account for particular audiences and will lessen confusion.

Military Liaisons Are Worth The Money

Especially if they were stationed at the base your contract is at, even better if they were in the same unit and command hasn’t changed. That comradery is invaluable and the preexisting relationships will make your life infinitely easier. They do cost a lot of money, and normally their solitary deliverables are esoteric, however the difference is directly noticeable.

You Are Contributing Most Likely to a War Effort, Not a Random Business

Within a military contract the work that you are doing has severe impacts that are by and large not found in the private sector. Sure, there are definitely outages which effect private business and that is no good; however they don’t affect people in the field that are relying on your system for war support. Most developers for example will recycle an App Pool to realize a new GAC versioned assembly being deployed and not bat an eyelash. Taking this mindset into a military environment will make your SharePoint contract the quickest one in federal history. Those actions ARE noticed, ARE logged, and will be examined. People will notice that brief latency shift, and you can bet your ass that you will hear about it later.

There are so many more, but that’s about it for now! Happy military SharePoint contracting!


ClickOnce Makes SDC Not Suck So Bad

Within federal computing systems, it is commonplace (and regulated) that a standard image be used when creating new machines that are going to be put on either NIPRNet (unclassified) and SIPRNet (classified) systems. While this is all fine and good, there is/was little or no control over what the user did after receiving said image, besides a loosely documented list of standard permission sets targeted to reduce malicious interaction. Something that is still being rolled out under some commands in the Air Force is called SDC, which stands for Standard Desktop Configuration, by which a user receives a standard pre-configured / packaged Windows image with common software. Included in the package are mechanisms that control the software that is in the future placed on the machine, and takes away a lot of rights from the user such as installing software packages as well as visiting certain web addresses. Besides the obvious conformity and maintenance benefits that this approach cultivates, it is also aimed at promoting better security as all users are ensured to have AV and Security packages up and running when they first get their machine, and masquerading malicious software cannot be installed by an unaware user.

While this all seems great and good from an aggregate benefits standpoint, SDC makes my life as a developer god damn terrible. Really bad. While I am a web developer, sometimes I don’t see a reason, it would just be easier to avoid, or a client application would provide a richer experience over building a web application / WebPart set. Unfortunately, I can build a great application using WinForm and WPF, however SDC won’t let me install my package since it is trying to deliver a non-standard software suite, and installing custom software is going to break that trend. So, either you have to fill out a stack of paperwork, or use ClickOnce.

ClickOnce as opposed to using the output from a VS.NET setup package uses two separate manifest files, the deployment manifest and the application manifest, the latter of which is meant to describe the application such as the files that build up the total structure of it, the former provided information such as software versions and other information such as update procedures. The deployment manifest is considered to be the starting point for the ClickOnce installation.

Back to how this relates to SDC stuff, my problem was I was unable, or had to go through a mound of paperwork, in order to install a couple SharePoint targeted, WinForms built, applications that some of my users needed access to. ClickOnce is non-intrusive to the users file system on their local machine, meaning there won’t be any registry entries, put anything into the GAC, etc. Furthermore, the files that are being used are stored in a ClickOnce run-time managed application store that helps to avoid SDC application collision as well.

Because of the above two conditions that ClickOnce promotes, I can install whatever fat / smart clients I want on my users machines now without having to go through any headache. If you are plagued by SDC and do some Windows development, I would encourage you to go the ClickOnce path. Yeah! :)