More on the Architect role and title#

As a response to my thinking about the role of the Technical Solutions Architect, Hans Verbeeck makes a good point on his blog on the snobism of Architecture:

It's like everyone needs to be one. Especially the top developers seem to be targeted. If you are a lead developer then you stand a big chance of being labeled an Aspiring Architect by some folks within Microsoft. IMHO, you don't need to be an architect to be architecting. I would even say that probably most of the good architectural work comes from Lead Developers who have a deep deep udnerstanding of what software is all about.

The architect title is perhaps so over-used that it's lost its meaning, and I think that's the source of a lot of confusion and opportunism. I've always had a bit of a love/hate relationship with the architect title, but I guess people (including me) need some way of categorizing their qualifications in a name that's well understood.

Clearly, there's something very different about what guys like Don Box and Chris Anderson do with internal frameworks such as WCF and WPF, and what I do as an external consultant on enterprise (business) frameworks. But within the boundaries of terminology that's out there, I positioned myself somewhere in the triangle.

I actually like Hans' image a lot about being positioned outside the triangle - which also puts me more outside the business domain:

So this certainly makes sense to me.

About the snobism and whether or not you should wear the architect title: I forgot about it until now but I think the solution already exists: the Microsoft Certified Architect Program should be - or become, as it's still in its early stages - the governing instance that hands out the "architect" credentials (in the Microsoft-space anyway). While a regular Microsoft certification - in my opinion - doesn't say that much about the real-life experience or qualifications of someone, this architecture certification is backed by a Review Board and a pretty heavy qualification process. This should make the certification much more credible...

But in the end, I think you'll always have to prove your worth on the dance-floor, if you know what I mean. So I'll just keep doing my moves and let's keep this party rolling :-)

Wednesday, May 31, 2006 12:07:28 PM (Romance Standard Time, UTC+01:00) #    Comments [1]  | 

 

The Technical Solutions Architect Role#

I've been doing quite some thinking about my role in the IT business lately, and a few recent posts have accelerated this even more... First, we have Joris Poelmans sharing and aggregating some thoughts about architects, architecture and the different types of architects (architect personas, if you will). And then we have Hans Verbeeck pointing us all to the Skyscrapr site, which is a site that serves as "your window on the architectural perspective".

All of these categorize architects in different roles in the business. Generally speaking, there are three personas most people seem to agree on (with my highly summarized descriptions that don't do the original posts any justice):

  • Enterprise Architect: responsible for the long-term strategic vision, thinking about the big picture together with the business and technical people; sets the direction for methodologies, frameworks and tools.
  • Solutions Architect: responsible for the design of applications and services within (part of) an organisation; works closely with the developers to make sure the goals of the business are achieved.
  • Infrastructure Architect: responsible for the data center, deployments and maintenance; makes sure the infrastructure on which the business applications run is reliable, manageable, scalable, performant and secure.

Since you're never only one of these profiles, Simon Guest adds to this idea by positioning yourself somewhere in the triangle formed by these personas, to indicate your relative strength in one particular area. If I were to call myself an architect (and sometimes - not only in my sleep - I do), I think I'd put myself somewhere here:

So I believe I'm mainly the Solutions Architect: driving the technical solutions to meet the business' needs. The problem for people that are in the consultancy business - like me - is that all these roles are defined within the boundaries of the enterprise. All of them assume that you are effectively part of the business. Since my role is typically shorter-term for each individual client (providing guidance and experience in the technology field rather than in the actual business domain), I often don't need (or want) to know too much about the actual business. The benefits of me having intimate knowledge about it are negligible most of the time, both for myself as for the customer.

So in that regard, I'd like to propose the term Technical Solutions Architect to describe what people like me do: this role involves setting up technical architecture, guidance, frameworks and documentation, performing code reviews, coaching, deciding on programming languages and technology stacks - all within a certain horizontal technical scope that may or may not be aligned with any vertical business structure.

What do you think? Would you agree? What role do you think you are?

Tuesday, May 30, 2006 9:08:43 PM (Romance Standard Time, UTC+01:00) #    Comments [1]  | 

 

Closing locked files that break the Team Build#

I was having some trouble the other day with our Team Build server when building a project that is used by an open Visual Studio instance.

Our setup is that we build our enterprise framework on the build server and then copy it to a public share so it can be used by the client projects. Now when somebody is actively developing a project in Visual Studio that uses this enterprise framework, we receive something like the following error in the build log when building the framework:

Copying drop to final destination
Copying folder "\\BuildServer\Drop\Framework_20060530.2\Release" to "D:\PublicShare\References\EnterpriseFramework\Latest".
D:\Build\Team\EnterpriseFramework\BuildType\TFSBuild.proj(168,5): error : A task error has occured.
D:\Build\Team\EnterpriseFramework\BuildType\TFSBuild.proj(168,5): error : Message = Access to the path 'D:\PublicShare\References\EnterpriseFramework\Latest\EnterpriseFramework.Common.xml' is denied.

So the open Visual Studio instance on the developer's pc seems to keep a lock on the XML file (for IntelliSense) on the build server, causing the build to fail. Now I don't think it's very nice of Visual Studio that it locks the file, but apparently that's the way it is.

So here is the unclean (you won't catch me calling anything I do 'dirty' of course) workaround I used to get rid of this sticky problem. In the build script, right before copying the files to the public share, I execute the following task:

<Exec Command="net session /delete /y" />

This simply forces a delete of all connected client sessions, closing all the handles of the files that are opened remotely. Problem solved - as long as we don't have the race condition where somebody would lock another XML file just between that command and the actual copy, but what are the odds... The only minor side effect is that the opened Visual Studio instance loses IntelliSense for some of the files it had locked, but we can live with that. At least it's better than breaking the build, right?

Tuesday, May 30, 2006 7:37:36 PM (Romance Standard Time, UTC+01:00) #    Comments [2]  | 

 

Visual Studio 2005 Web Application Projects Released!#

I don't know about you, but I've never been very fond of the new Web Project System in ASP.NET 2.0. I'm sure it has its advantages for some types of users but I've definitely had more than my share of problems with it. Specifically the way that it sometimes (and randomly) starts checking in binaries in Source Control has shortened my life with at least 4 months. Furthermore, having each page compile into its own assembly (by default anyway) and therefore not having a nice place to put assembly-level attributes or define strong naming that work on the entire website has surprised me (in a negative way, that is). What I don't get is that Microsoft had abandoned a familiar and working concept (the Web Application model used in the previous versions of Visual Studio) and replaced it entirely without supporting the old way of working. To me this has always been a major breaking change, and a cause of much frustration.

Well, the pain has now officially ended: the Visual Studio 2005 Web Application Projects has been released, meaning that the old model is back with a vengeance. With a free download from Microsoft, you can get your familiar working environment back in Visual Studio 2005, but with lots and lots of improvements over the previous versions of course (not even mentioning the fact that it's now ASP.NET 2.0 with all its goodness around it).

Some highlights:

  • A project file (which I don't consider a feature, more a bugfix over the previous model)! This fixes the problems with the references getting checked in, and lots of other things.
  • Because of the project file, you also have pre- and post-build events again (the new Web Project System doesn't support them).
  • You can create working Web Setup projects again, containing the content and primary output of the project. With the new Web Project System, you have to download and install a separate update (the Visual Studio 2005 Web Deployment Projects).
  • It builds one assembly by default. This fixes the problem with the assembly-level attributes and strong naming.
  • The Global.asax file isn't ugly inline script anymore but a proper class in a code-behind file. The "Application_Start" and similar methods are still "magic" though, discovered through reflection I assume, in stead of properly overriding them from the base class or something.
  • No more Frontpage Extensions required. Be gone, _vti_*!
  • Built-in Development Web Server. Be gone, IIS! Well, not for enterprise scenarios of course, but it's still a very nice feature :-)
  • MSBuild support.
  • Better web publishing options.
  • ...

I've immediately installed and tried it and it works great! One specific detail that I think is a very nice feature (just to show that it's not a quick fix of the old model to run on Visual Studio 2005 but a real full-blown upgrade) is the "Create Virtual Directory" button in the project settings, which allows you to setup a virtual directory in IIS without having to go to the IIS console:

Great!

Anyway, this add-on has made me very happy with ASP.NET 2.0 again. It's the little things that make the difference, but the big things in this case made my day :-)

Blog | Programming | .NET | ASP.NET | VS.NET
Thursday, May 11, 2006 8:30:11 AM (Romance Standard Time, UTC+01:00) #    Comments [0]  | 

 

InfoPathHelper v1.1: add offline support to InfoPath!#

It's been a while since I released the original version of InfoPathHelper, a small reusable .NET library you can use to add offline support to InfoPath forms. I still think it's a nice little utility, and it makes me proud that even the InfoPath folks think enough of it to link to it on their Office Developer Center!

Unfortunately, I've always found it hard to really promote it since there was this one nasty bug that didn't make me very proud: it would sometimes blow up when caching data from a Web Service. But today, I'm happy to announce that I've fixed that bug and added a few other tweaks as well so I believe it's now a fully functional product!

I'll repeat the elevator pitch from my original post here just to round up what it does:

InfoPathHelper is a small reusable .NET library you can use to add offline support to InfoPath forms. That's right, you're finally able to make InfoPath a real smart client that is offline capable of submitting forms and querying data sources, without any extra security requirements whatsoever.

For the end user, the form will appear to continue working when the machine is offline or when the target you're submitting your form to is unavailable (a Web Service, a Sharepoint site, ...). The next time the machine goes online, any pending requests will be submitted. The same goes for querying data sources (files on a network share, Web Services, ...): if they're not available, the data will be taken from the local cache until the next time it can be refreshed.

For a developer using the InfoPath 2003 Toolkit for Visual Studio .NET, it boils down to inheriting from the CachingInfoPathForm base class, changing your submittal options to use form code, deleting the messy generated boilerplate code (you get cleaner properties and events for free in stead) and calling a few methods depending on your needs. The following example shows how to enable offline support for a form that has a submit data adapter named "WebServiceSubmit" and a data object named "Countries".

public class MyCachingForm : CachingInfoPathForm
{
    [InfoPathEventHandler(EventType=InfoPathEventType.OnSubmitRequest)]
    public void OnSubmitRequest(DocReturnEvent e)
    {
        // Attempt to submit the request and return a value to indicate if it worked.
        e.ReturnStatus = ProcessSubmitRequest( "WebServiceSubmit" );
    }

    [InfoPathEventHandler(EventType=InfoPathEventType.OnLoad)]
    public void OnLoad(DocReturnEvent e)
    {
        // Attempt to submit any cached requests and query a data object.
        SubmitCachedRequests( "WebServiceSubmit" );
        QueryDataObject( "Countries" );
    }
}

If you're wondering where the cached data is stored without needing any extra security requirements: welcome to the magical world of Isolated Storage :-)

Changes in v1.1:

  • Strong-named the assembly. This is needed for the offline caching to work properly, otherwise a published form would apparently get a new directory in the Isolated Storage cache each time the form is run.
  • Added the AllowPartiallyTrustedCallers attribute to the assembly. This is needed to allow the now-strong-named code to run within InfoPath.
  • Fixed the bug where a "This DOM cannot be loaded twice" COM exception would be thrown when caching data from a Web Service.

Thanks to David Downs at Microsoft for reporting and solving the issue with the isolated storage, and thanks to both David Downs and John Boesen for coming up with part of the solution for the bug with the Web Service!

Enough talk, here's the goodies:

The JelleDruyts.InfoPathHelper 1.1 library and documentation (125,12 KB)
The JelleDruyts.InfoPathHelper 1.1 library, source code and documentation (244,17 KB)

Tuesday, May 09, 2006 7:16:12 PM (Romance Standard Time, UTC+01:00) #    Comments [5]  | 

 

MSDN Connection & Book of the month discount#

Our local MSDN Belux guys have created an "MSDN Connection" site where you can get an RSS feed of MSDN news, access to developer centres, downloads, events, and much more. Not only does that sound pretty interesting in itself, but members also get a free subscription to the Dutch ".NET Magazine" and a 40% discount on the book of the month.

In May, this book is no less than Jeffrey Richter's most excellent "CLR via C#" (the second edition of his must-have "Applied Microsoft .NET Framework Programming"). I was just about to order a copy, so count me in for that discount!

And all of this for free... Great work guys!

Thursday, May 04, 2006 9:40:41 AM (Romance Standard Time, UTC+01:00) #    Comments [1]  | 

 

All content © 2010, Jelle Druyts
On this page
Recent Photos
www.flickr.com
This is a Flickr badge showing public photos from Jelle Druyts. Make your own badge here.
Advertising
Top Picks
Statistics
Total Posts: 350
This Year: 4
This Month: 2
This Week: 2
Comments: 526
Archives
Sitemap
Disclaimer
This is my personal website, not my boss', not my mother's, and certainly not the pope's. My personal opinions may be irrelevant, inaccurate, boring or even plain wrong, I'm sorry if that makes you feel uncomfortable. But then again, you don't have to read them, I just hope you'll find something interesting here now and then. I'll certainly do my best. But if you don't like it, go read the pope's blog. I'm sure it's fascinating.

Powered by:
newtelligence dasBlog 2.0.7226.0

Sign In