Of late, I've been struggling with how to integrate formidable architecture tasks for large projects within the Agile process.  Small projects, maintenance work, pretty much anything that is well understood is OK for "Design as you go" or "Design only what you need" type approaches.  But a ground-up design and build of a large system really almost requires that some general patterns and principles be set forth in advance. 

• "ArcGIS Server will support the need for spatial data in the web tier"
• "Does the client have an ESB in place?"
• "We're going to have a provider pattern for the data tier...."
• "We're going to use a service broker..."
• "We'll use SODA for data access..."
• "The UI will be Microsoft CAB..."

...are all the types of examples I'm thinking of.    Clearly doing a full on discovery and architecture for 6 weeks defeats the point of agile processes by hamstringing your ability to evaluate and adapt on down the line. Plus it's a waste of time...you haven't done stories yet, you haven't prioritized features and functions with the client, and you're likely to either miss something or design for an eventuality that will be tossed out later.  You've also short circuited the effectiveness of iterations and sprints by hopping in your ivory tower and demanding all the information up front.  So what's an architect to do?  Well, first thing's first...you need to remember your core values of courage and humility.  If you can do that, then read on...

Read the rest of this post »

Last week I posted a rather verbose discussion of some modifications to a PlugIn pattern that  I made to make each plug in configurable at run-time, accepting different parameters as inputs to discrete running instances of a plug-in.  The point being, rather than having plug-ins that do repetitive tasks with little or no run-time customization, I wanted users to be able to tell the system exactly what the plug in should do through some sort of configuration UI. For example, "Send Message" wasn't good enough...I wanted the message to be sent to a configurable address (or fax number, or MSMQ) with a personalized subject and message. My goal was to build out a test project and provide it all here but I'm swamped right now so I'll provide some of the API mods and code examples here and maybe get back to a more complete implementation later on (in all my free time). Since my IPlugIn interface and the method for fetching plug in information using System.Reflection largely follows the example that I found here, I won't delve to deeply into that. But let's look at some of the mods I did make...

Read the rest of this post »

Got the go-ahead last Friday and booked my travel for the 2008 ESRI Developer Summit.  And I managed to get a hotel to boot! Pretty excited to be going this year...for one it'll likely be a good ArcGIS Server brush up for me...I spent about a year away from the geospatial industry and only recently leapt back in so I missed the 9.2 goodies. For another, it'll be a good break toward the end of the winter to renew old friendships, and make a few new introductions.  In contrast to the user conference I really feel this event is great not only for its technical education aspects and face time with the ESRI tech folks, but also for getting exposure to how others do things, getting new ideas for upcoming projects, and generally putting yourself and your skills out there for a sanity check every once in awhile. Looking for work? Think I'm full of malarky? Just want to say hi? If you recognize me flag me down in March...

The last few large projects that my team and I have worked on have involved the use of offshore development resources as a supplement to the onshore (stateside) development team.  I can see why companies lean toward the relatively economical pricetag of offshore developers, but the results I've seen are so varied that I'm still not convinced that this approach is for everyone, despite the fact that the industry seems to be rushing headlong in this direction. Back in 2006, Martin Fowler published a good article on how to make the most of your offshore development resources here. In addition, Stephanie Moore, Liz Barnett, and Kimberly Dowling have collaborated on a well thought out article on how to leverage Agile processes and offshore development resources effectively.  Despite the dates on these articles, I think their points still hold, but in cases where my teams have had the most success, I've noticed some distinct trends. In addition to the advice given in the articles above (and the advice of others too numerous to list...just go a google'n) I'd add (or re-inforce) the following:

Read the rest of this post »

As a solution architect, I'm usually the team member that sets technical direction for a given project and it usually falls to me to negotiate the process with the client that will be used for design and development.  We're trying to move more toward the "Agile is the way we do things" mantra, but I'm not yet ready to slap the guy keeping the lights on.  One of the first questions out of my mouth on a new project or with a new client is, "What's your process?".   Over the past couple of years I've gotten a variety of answers including:

• We don't have one. What's a process?
• We use a hybrid process (perhaps with some agile features).
• Waterfall (~shudder~), spiral, etc.
• We have a formalized Scrum process with "n" scrum masters onsite.

Clearly I'd like to hear that last answer a lot more in the geospatial realm, but more often than not its one of the first three...and that's fine.  As a consultant, it's my job to not only do design and development, but to educate and leave a client with the tools and skills to do their business better when my contract is up.  As the long as the process they use works for them, everybody's happy. Interestingly enough, when I ask them to expound upon their answer and lay out the details for me, some interesting things come to light.  First, many folks that claim to have a formalized agile approach don't have anything in place that a Scrum team would call recognizable...but they'd picked up some lingo along the way and bandied it about profusely.  Second, others who gave one of the first three answers above look pretty to agile to me upon further review.

Read the rest of this post »

As we're in a pretty good growth phase right now, my team is looking for highly motivated self-starters to join our GeoSpatial Practice.   A Microsoft Certified Gold Partner and ESRI Business Partner based in Denver, CO we're a tight knit group of consultants working on some interesting and cutting-edge solutions for both web and desktop GIS in a variety of vertical markets.  While we are currently primarily an ESRI shop, we are developing new business in the Microsoft Virtual Earth market as well and I've got my eye on developing some work in the OGC realm also. 

Critical Skills

• .NET Frameworks 2.0, 3.0, 3.5 (C#)
• Experience with ESRI ArcObjects and both desktop and web product suites including ArcGIS Server, ArcGIS Desktop, ArcIMS, ArcEngine, etc.
• ASP.NET, Microsoft Ajax
• Bona fide skills in OOP/OOD and SOA development

Other Desirable Skills

• The various offerings coming out of Microsoft's Patterns and Practices Group (e.g., Enterprise Library)
• Experience developing against Microsoft's Virtual Earth 
• Familiarity with industry standard design patterns (service broker, provider pattern, MVC, MVP, etc.)
• Background, training, and interest in GIS
• Design or architecture experience including UML, RUP, etc.
• Experience working in agile environment
• Prior experience in a consulting role (read: the "soft skills")

Typical Projects

Frequently you'll need to shift quickly between projects for a variety of clients.  You may have the opportunity to collaborate with your team on:

A computer aided dispatch system for a large client in the public safety market - developing the next generation of CAD systems and integrating ArcEngine and geospatial algorithms within a .NET-based enterprise class system.

A web-based retail site location system for a "big box" client - integrating traditional tabular demographic and other attribute data with ArcGIS Server to produce a spatially enabled system for selecting retail sites and performing analysis against existing sites.

A web-based system guaranteeing safety for the oil and gas pipeline industry - using ArcIMS and/or ArcGIS server to allow the petroleum industry and the public to communicate regarding infrastructure locations, potential problems with planned excavations and development projects, etc.

Multiple large metropolitan water projects - using your experience to help your team undertake ground-up software design, development, and implementation efforts for some of the largest metropolitan water managers in the US.

Contact

You can drop me a line here if you have any questions or would like to pass your resume along. Alternatively, take a gander at our site over here where you can read what we're all about and find links to all of our opportunities from the Careers link. We're looking forward to hearing from you!

So I've been having a few "geek" laughs courtesy of the folks over at Worse Than Failure. If you're having a bad day at the keyboard or just need a laugh, check this site out. The stories are made even better by the fact that their URL (www.thedailywtf.com) acts as a double entendre. WTF = Worse Than Failure ??? Maybe not so much after reading a few of these.

Okay, okay...so I've pimped these guys out before but I'm gonna' do it again.  I'm really impressed with what The Carbon Project has to offer and I see very little on the blogosphere to indicate to me that they're gaining a wider audience.  (Although curiously I see when I Google them that ThinkGeo is taking a swipe at them in the sponsored adds.) A few years back, these folks started out by providing an easy to use API and architecture for integrating OGC web map and web feature services.  As OGC specs began rolling out the door and evolving, they kept pace which was nice because at the time I was involved in a lot of OGC initiative work and could really leverage an API that meant I didn't have to read the spec and build the XML parsers and serializers myself. Fast forward to today. Their original Carbon Tools API has been expanded to include not only your standard OGC interfaces (WMS, WFS/GML, CS-W, etc.) but also Virtual Earth, Google Earth, Yahoo! Maps, and ESRI Shapefiles. In addition, they've created a product called CarbonArc that provides full geospatial interoperability for the SDI 1.0 baseline directly inside ArcGIS 9.2. Clearly, full geospatial interoperability isn't just a pipe dream for these folks...they're making it happen. But the things their doing with Geosocial Networking via ((Echo))MyPlace and the Carbon Cloud are way cool and will definitely be receiving some attention from me in the near future...if for no other reason than it'll be fun to play with. Oh! And Jeff Harrison, the Carbon Project CEO, has a blog here.

As consultants, my team is seldom gathered all in the same place at the same time.  While we do have several large projects that frequently occupy many of us, we've got lots of smaller consulting gigs that keep us running around the greater Denver area a fair amount.  However, we all collaborate regularly on little business development one-off demos, pet projects for conferences, and frequently collaborate on client projects when not colocated.  One challenge that we've been having is maintaining the integrity of our central TFS store at the office without a nightmarish scenario of disconnected edits and merges (ever try that with a busy form designer???).  In addition, we needed a central information store and place folks could go to ensure they're all on the same page with regards to upcoming work items, standards for a given project, who is working on what bugs, etc. I figured SubVersion would be a good free source control resource whilst we were all disconnected or in different locations, but I just don't have the time to set up the server side stuff, etc. and get all this stuff whacked together right now. I read Dave Bouwman's blog on a pretty regular basis since we used to work together and wouldn't you know it, he's got a great little post that, in part, extolls the virtues of Assembla. Turns out that this site is just the ticket. You get SubVersion and TRAC off the bat and also get a wiki and access to some Scrum tools as well. And since it's free...it's me. We were able to get a site up in no time and get several of our folks all collaborating online on several project demos we're working on for upcoming conferences. The wiki and the Scrum tools will allow myself and the business development folks to track progress and issues as well. Check it out and see if it's for you and your team. From my perspective this sort of resource is ideal for these smaller projects where folks are not necessarily colocated.  And the Scrum components keep us all honest and agile...allowing reports from team members, scheduling of stand-up meetings, and chat as well.

A short while ago, I was working on the architecture of a large system that needed to perform a variety of "tasks"...specific actions that could be triggered by the user or run internally by the system through code according to a prescribed recipe or set of conditions.  The issue at hand was, the variety of these widgets that would ultimately be implemented was not known a priori.  In addition, the functions to be run needed to be

1. Data driven...actions and functional code outcomes needed to be based upon information in a database 
2. User configurable at run-time...each function or action did not simply execute in the absence of custom user inputs, but could be scheduled or otherwise configured.  For example, "send a message and attach this specific document to that message".
3. Persisted...essentially the custom actions could be planned, added, or removed from a list at any time so we'd need to perform CRUD operations to store and edit instances of each custom action.
4. Extensible post-rollout...the application was going to be delivered in phases with planned enhancements delivered via service packs or other update mechanisms over time.  In addition, customers may wish to purchase custom coded widgets or develop their own.  Constantly recompiling of the entire system to support new functionality was out of the question.

Read the rest of this post »