In order to meet ever-increasing customer demands and compete on a global scale, many organizations need to be able to fold new systems and/or new features into existing systems quickly and cheaply. These organizations — and perhaps yours — have portfolios of existing systems and infrastructures that were implemented literally decades ago.

These “legacy” systems, while well-architected for the demands and market conditions of the past, have often become increasingly complex through the years and more costly to maintain. What’s more, these systems are based on technologies that simply don’t provide the flexibility and disciplined agility that modern programming languages and frameworks can. Read More…

In my job, I have an opportunity not afforded to most: I get to listen to all of the risks, challenges, and issues (a.k.a. problems) that other organizations face. (I know, you’re jealous, right?)  From issues with large-scale hardware deployments to the risks of implementing new federal bureaucratic form processing, I get to hear it all.  Without fail, nearly all of those discussions start with someone in the room declaring, “We do it different here.”

If I had a dollar for every time I heard, “we do it different here” during a federal project kick-off meeting, well…I would have about twenty or thirty bucks, but that’s not my point. The point is you don’t do it differently!  Human nature is human nature and given similar constraints, regulations, policies and procedures, the outcomes will be similar.  Beyond the obvious irony in nearly all organizations declaring their uniqueness, I am struck by the actual similarities of the problems.

Read More…

It should come as no surprise that Microsoft’s strategy for SharePoint 2013 is cloud-based, SaaS, Hosted Services or whatever you want to call it.  Whatever the name, the outcome is that custom, server-side code is no longer the way to go in the SharePoint world.  This brings into question the fate of one of the workhorses of SharePoint since 2003: the Event Receiver.  Microsoft has done a great job of exposing web services and creating the Client Side Object Model to enable scripting, but that doesn’t work when your application needs to react to an event that occurs in SharePoint.

SharePoint workflow could provide some of that functionality, but there is an overhead cost to workflow.  When architecting a SharePoint-based solution and the question “Workflow or Event Receiver?” comes up, I always prefer event receivers until it’s proven that the process needs a workflow.  If all the process needs to do is fire off an e-mail or update a field in another list or database, then why incur the overhead of a workflow when an event receiver will do the job with minimal management and overhead?  But that doesn’t work in an app for SharePoint or in a hosted environment that doesn’t allow custom code…or does it?

I’m guessing you can tell from the title of this post what the answer to that is — yes, with remote event receivers.

Read More…

Happy Friday! Here are some great posts from AIS team members‘ personal blogs…

Securing a Windows Azure endpoint…the VALID way…: “Many cool new services are being rolled out in the Windows Azure platform, but there is one feature that has been in place since Azure went live that is still very valuable to me: the ability to quickly roll-out locally developed functionality to the web using Web or Worker roles.” (bwodicka.wordpress.com)

Enable Automatic Code First Migrations On SQL Database in Azure Web Sites: “Azure is becoming increasingly easier to use – especially with features like Azure Web Sites. Being able to use Entity Framework Migrations in Azure makes deployment easier than ever.” (Steve Michelotti)

Creating an Offline Web Platform Installer for Service Bus 1.0: “Service Bus 1.0 is available only through Web Platform Installer at this time and it’s not readily apparent how you might use WPI for a network isolated environment. Hopefully this will help…” (cromwellhaus)

Netizen – Windows 8 app that makes it easy to follow congressional votes: A little extra background on our free Netizen app and why we created it. (Fleeting Thoughts)

Resources for How to Raise A Geek: “A list of tools, books, and ideas to help parents raise a geek. Raising a geek will bring you closer to your children, give them tools for the future, and you might learn something along the way.” (Steven Suing’s Blog)

AIS is hiring! Come join our team of smart, passionate innovators. View all current job openings here

ASP.NET 4.5 has introduced some cool new features and enhancements for web developers using Visual Studio 2012. One of the new features introduced deals with the framework’s Web Forms technology. In previous versions of ASP.NET, if you wanted to display data-bound values in a control, you needed to use a data-binding expression with an Eval statement, e.g. <%# Eval(“Data”) %>.

Using an Eval Statement to display data-bound items

This approach works, but it introduces a few problems. In my experience, the Eval statement approach is prone to developer error. If you are like me, then you have undoubtedly misspelled a member name or tried to bind to a  nonexistent member. These mistakes, while trivial, tend to make themselves known only at run-time thus making them more difficult to track. Due to the Eval statement being dynamic in nature, it is impossible to enforce compile time error checking.

With ASP.NET 4.5, we can now take advantage of Strongly Typed Data Controls. These controls allow us to specify the type of data the control is to be bound to, providing us with IntelliSense (which solves another problem for me: remembering which members belong to the DataSource) and compile time error checking. Adding a strongly typed data control requires minimal effort!

Read More…

With the SharePoint Conference 2012 behind us, I have been reflecting on our SharePoint journey so far…and on the road ahead. And what an incredible journey it has been! SharePoint has allowed AIS to build mission-critical applications for various large federal government agencies and commercial organizations. And not just ECM or document management systems (which are great workloads enabled by SharePoint) but enterprise-class applications for tens of thousands users (such as the FBI’s Delta Project), built using SharePoint platform elements such as workflows, lists, libraries, search, etc.

This blog entry is comprised of two parts. The first part will focus on the SharePoint journey so far. Through a series of short video clips, I will present some of the key insights we have derived over the many years of building custom applications on SharePoint. We will end this the first part with a short demonstration of SharePoint-based Case Management application that brings together many of the key concepts. The second part will focus on the road ahead and the most important enhancements made in SharePoint 2013. Read More…