On this page.... RSS 2.0 | Atom 1.0 | CDF
# Saturday, April 1, 2006

If anyone's like me and is used to using pubs for sample applications, you might find that you miss it when you install SQL Server 2005.  Now I'm sure there are more ways to go about getting it back, but for the heck of it, I did a local hard drive search for pubs, and look what it turned up.  Not only do I have a script to install pubs but also Northwind and others.  The directory on my machine is E:\Program Files\Microsoft.NET\SDK\v2.0 64bit\Samples\Setup, but I figure it'll be under the Samples\Setup of wherever you happen to have the 2.0 SDK installed.   Ahh.. pubs.. dear old friend... 

Saturday, April 1, 2006 4:27:49 PM (Eastern Standard Time, UTC-05:00)  #    Disclaimer  |  Comments [2]  | 
# Friday, March 31, 2006

In time, I hope to be able to look back on this day and think wow, was I ever that ignant?  Something that has plagued me and many others in ASP.NET 1.x has been resolved (no pun intended) in 2.0, viz. a static framework method to resolve an application-relative URL into a server-relative URL.  This is one of those problems that you feel like there must be a solution for, but maybe you just could never find it, or maybe you just didn't take the time because you created a solution that worked well enough.

In 1.x, on virtually every application I wrote, I ended up creating some utility method that would essentially do what the ~/ would do in a user control, which is equivalent to calling the ResolveUrl method.  The main idea, of course, is that we need a URL that is valid, regardless of the context, regardless of whether or not the application is being run on a development machine in a virtual directory or on a production server off the root.  Or maybe we just wanted to make it easy to change the virtual directory name--you know how fickle those users can be when it comes to what they want to see in the address bar! :)

So what did you do in 1.x?  Specifically when you didn't have a readily-available control to call ResolveUrl on?  If you're anything like me, DotNetNuke, or sundry others, you probably made some utility function that would squish the application path in front of the URL using the Request.ApplicationPath, if you could, or if you were really knowledgeable, the HttpRuntime.AppDomainAppVirtualPath property.  (Shh, don't tell anyone.. apparently, I'm not that knowledgeable as I just had this pointed out to me by David Ebbo; I usually hacked that one as well, storing it in my Global class by ripping it off of HttpRequest or worse, specified it in the web.config... oog).

Well, even if you do get the application path, you still have to write a function to munge it with the relative URL to come up with what I call the server-relative URL (i.e., an URL that starts with /).  Good grief!  Couldn't they have a function to do this that is static (doesn't require a valid request context)!?

Never fear, in 2.0, we have a neat new utility class called VirtualPathUtility!  You can read through the docs to figure out all the neat-o features, but the only one I particularly care about is ToAbsolute.  This one is, as far as I can make out, the functional equivalent of ResolveUrl, so now I can resolve server-relative URLs from app-relative ones without needing a valid request context and without writing my own functoid for it.  Woohoo!  Note: I say "server-relative" because the URL is relative to the server root.  For some reason, the MS folks call it "Absolute."  To me, absolute would include the full URL, including server.  I'm sure they had a good reason for it...

So that's it.  No more messing about with all that garbage.  Just declare all of your URLs using ~/, and call VirtualPathUtility.ToAbsolute to get a URL that should be valid regardless of your deployment environment.  Too cool! 

Edit: Forgot to give credit to David Ebbo on the Web Platforms and Tools Team at Microsoft for pointing out this new utility class to me.  Thanks, David!

Friday, March 31, 2006 9:50:42 PM (Eastern Standard Time, UTC-05:00)  #    Disclaimer  |  Comments [2]  | 
# Friday, March 10, 2006

asp.netPRO is doing their yearly survey to see who's the best of the best.  I hope you will consider voting for ASPAlliance.  We've been working to improve your experience over the last year, and our vision is to keep improving and providing high-quality content for Microsoft developers in the future.

Also, if you don't know whom to vote for in hosting, go for Server Intellect.  They do an awesome job of providing affordable, high-quality hosting and enabling you to take control.

Go vote!

Friday, March 10, 2006 6:18:18 PM (Eastern Standard Time, UTC-05:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, February 23, 2006

I just read an article in The Architecture Journal about this thing called BSAL (Behavioral Software Architecture Language).  The author bores us with the same old history of problems with docs becoming out of date, claiming that BSAL is the answer to all that, saying "the important addition that BSAL brings into play is the common, standard usage of a few building blocks in software definition," which are loosely "system, subsystem, state, behavior, and message objects." 

I'm having a real hard time getting excited about this.  In my (and many, many others') opinion, the real problem in business software engineering is not so much that documentation gets out of date (though that is definitely an issue).  The problem is that even our documentation--much less the implementation!--does not accurately describe or meet the actual business needs.  Further, because business needs constantly change, having a better way to do upfront design doesn't (and has proven not to) really solve the core problems; you need a way for your implementation to move with the business changes and, ideally, have that reflected in your design documents.

While I can see the value in having a more accurate overview of the system (and I'm really keen on behavior/process-based design), I think that BSAL is attempting to solve the problem from the solution domain perspective and not the problem domain perspective.  The behaviors that architects of business systems need to be concerned with, in my estimation, are not so much the behaviors of the system (in themselves) but the behaviors of the classes of business objects and, in particular, how those specific behaviors support a greater business process.  Any software architecture language that wants to solve business problems should speak in terms of the business so that the formalization of business processes and behaviors become the actual behaviors of the system.

And that's precisely why I see so much promise in the broader application domain-specific languages.  You can define DSLs that allow you to speak to specific problem domains.  Not only that, these languages can not only generate high-level stubs but can also potentially generate real, executable code.  They do so in ways that are far more pertinent to the problem at hand than any high-level, universal SAL like UML, which, by the way, what's so much greater about BSAL that UML doesn't provide for?

It is entirely possible that I'm not getting the real benefits behind BSAL, but as it was explained in that article, I just don't see it.  I think the software factories initiative has far more promise to make our industry better than yet another UML.

Thursday, February 23, 2006 2:56:55 PM (Eastern Standard Time, UTC-05:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, February 17, 2006

Have you heard of the International Association of Software Architects?  If you’re a software architect, or even an aspiring one, you need to be aware of this inspiring organization.  While some architecture organizations focus on a top-down, global or vendor-based approach, the IASA focuses on all IT architects at every level, regardless of their vendor affiliations, starting at the local area.  To better serve this end in the central Florida area, Tom Fuller and I have started up the Tampa Bay chapter

The IASA’s sole aim is to provide value to each other and to make IT/software architecture a full-fledged profession with a significant knowledge base and quality controls.  Key goals of the IASA are:
   • To provide the latest news and articles in the architecture discipline.
   • To support the establishment of strong relationships among architects both as peers and as mentors.
   • To support and fulfill the needs for working groups as challenges in our industry call for them.
   • To provide both local and a global forum for debate of issues pertinent to the profession.
   • To enable each and every architect the ability to grow in the profession and to impact the software industry in positive ways.

If you want to know more about this organization, please visit the IASA Web site or contact Tom or me directly (or even comment on this blog).  To get involved and be aware of important announcements (such as meeting times) in the Tampa Bay and central Florida area, register on the site for the Tampa Bay chapter.   We look forward to seeing you there!

Friday, February 17, 2006 4:00:07 PM (Eastern Standard Time, UTC-05:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, February 15, 2006

This is a continuation of a discussion I began with a short article on ASPAlliance.  Tom Fuller had some good comments, and I've since been discussing the subject with some other experienced developer-architects.  Both Tom and they have very valid and interesting concerns about what I'm proposing.  The biggest pushback has been on my definition of the architect role as being 1) not an überdeveloper and 2) not necessarily more valued or well-paid than developers.  Of course, there is also some vagueness around just what an architect would do, and that much, at least, was intentional.

First, let me say these propositions are not thoroughly baked in my mind, and rather than trying to tell everyone exactly how it should be, I’m just tossing out some ideas that may or may not pan out in the end.  This is the nature of thoughtful dialogue, and I appreciate anyone who has constructively critical feedback.  As such, I’m not promising any sort of unbreakable consistency on my part as the ultimate solution is the goal and not the presupposition of this dialogue.

Now, the core issues with both of the objections mentioned above are, I think, inherent in the way the architect role is perceived today.  Because architects are expected to design systems down to even the class/interface level, they are expected to be developers, and because they’re expected to know everything developers know and more, they should naturally be more valued and paid better by the business.  It may be true that this is the way things should be and continue to be, but what I’m suggesting is that this view of the architect role is in fact not optimal to achieve successful projects or even enterprises.

I think that if we did have a complete career track (such that architecture is in fact a distinct but related discipline), an architect's duties would be distinct enough from a developer's to not require “real-life” dev experience in order to be good.  This would be achieved not just through training or book knowledge but also from experience as an architect, starting as a junior and being mentored by senior architects.  This way you are still learning from experience but instead of learning developer lessons, you're learning architect lessons.

Similarly, because architects are responsible for a different set of problems, they don’t need to be an expert developer in the first place.  While their role may ultimately be perceived as more valuable to a business, it would not be due to simply being a developer++ but rather due to the distinct value they bring to the business.  And even within the architecture discipline, I imagine there’d be different levels of experience as well as different kinds of architecture responsibilities (solution architect, enterprise architect, and infrastructure architect, for example).  You’d have some junior architects who are less valued (paid less) than some mid-level or senior developers.

This does not preclude some cross-over between the disciplines—a senior developer would likely have a faster track to a senior architect role than a junior architect right out of college because there is most definitely a shared body of knowledge between the two. It may be that said developer simply has not had the opportunity to pursue an architecture path, or it may be that due to fiscal constraints, he’s had to play both roles and hasn’t been able to fully pursue architectural interests, which is often the case for smaller shops and consulting firms.

Of course, all of this implies a redefinition to some extent of the role of an architect--he'd take on some of what some people think of as business analyst functions, some of what might today be seen as project manager functions, some of what may be seen as QA functions, and even perhaps some of what might be seen as developer functions. 

The architect would take on the responsibility of understanding and assisting BAs in analysis of the business in terms of how and where technology would best apply to solve business problems.  She’d be responsible not for scheduling and facilitating the keeping of the project on track but rather in ensuring that the business needs are sufficiently being addressed by what the developers are building.  In ensuring the output of the project is aligning with standards and business needs, she serves in a kind of QA role.  And she might do some development of cross-functional solutions like authentication, authorization, and auditing, but at least she’d take on the specification of how these kinds of things should take place to ensure consistency in areas of cross-functional functionality and within the greater enterprise architecture.

I don’t think it is fruitful to further delineate responsibilities at this level because the specific responsibilities will vary based on the size of the development team(s) and, more importantly, the methodology being used.  The key realization is that the architect is the hub between these various disciplines, not some other person (such as the BA or PM).  The reason I think the architect should be this person is that the product being built is software, and you need an individual who is very well-versed in software design, the trade-offs, the technologies, and the patterns but who can also get and jive with the other disciplines to ensure that everything is working together in a complete picture of a well-oiled machine.  It is a very strongly technical position, but it is also a very strongly people- and business-oriented position.

To facilitate this change or (I’d suggest) better definition of an architect’s role, he'd be divesting himself of what some people see as being the “ivory tower” architecture role--the idea of a specification of the system to its lowest level of abstraction and the handing down of such a specification from on high to developers.  This is key in getting developer buy in to any kind of idea of architect, and it is key in the architect being able to take on a more holistic role in terms of the project.

Most devs want to do some design work—within their technologies and within specified business requirements, and I think in this world I'm proposing, they would.  The role of the architect in terms of system design would definitely be the big picture concerns--cross-functional and non-functional, cross-application, technical requirements, etc.--and the architects and devs would have to work together.  Design could not be done in a vacuum in either role.
At this point, the term "architect" comes into question as the metaphorical value becomes less.  Indeed, I think architect is probably not the best metaphor because we're dealing with designing computer systems that make business processes more efficient, not with designing a free-standing physical building.  So perhaps we've approached the problem wrong in the first place--the laws of physics don't change every week, but business processes can and do.

It may be that the role I’m envisioning is not in fact a refining of the architect role but rather the specification of a new distinct role.  But if that is the case, I question the value of thinking of architects and developers as distinct roles, which speaks volumes to the current confusion around the roles today.  Most developers do design work, and if the only distinction between the roles is whether or not design work is done, where’s the value in the distinction?  Why not just call all developers architects or all architects developers?

Truly, though, I think there is a distinction—the one I am trying to draw out via further refinement of what we might think of as the architecture discipline.  It’s partial refinement, partial redefinition, but I tend to think that this refinement and redefinition is necessary to not only enable the discipline to grow but also to be able to communicate a distinct value that a person in the “architect” role brings to the table.  He’s not just a developer (though he certainly can have development skills), he’s the key role—the hub between the disciplines we’ve come to realize should be involved in software creation—that ultimately makes or breaks a project.

That’s not to imply that the other disciplines do not add value by any means or that their failure will not break a project as well.  But the state of things today seems to be that these disciplines have a hard time of coordinating and actually coming up with a coherent solution that truly meets the business needs.  Up to this point, we’ve been refining those disciplines in themselves and trying to define processes, methodologies, and documentation to solve the problem of failing projects or projects that just aren’t solving business issues.  And last I read, as an industry, we’re still doing terribly poorly when it comes to project success from a business perspective.

So I think rather than solving the issue by further refinement of the currently-known disciplines, processes, and methodologies, we need to pull architecture out of the development discipline, pull out of development what needs to be pulled out with it (which does not mean all design), and give architecture new responsibilities (or at least better defined ones) that essentially relate to being the technical hub of the project or enterprise.

If at the end of the day we still call it the architect role is irrelevant to me.  I don’t think it fully speaks to the role I’m imagining, but it does to some extent, and since the term is fully entrenched, it may not be worthwhile completely changing it but rather just redefining it to something more pertinent to our industry that deals with business processes, not gravity, mortar, wood, plumbing, and electricity. 

On the other hand, software is a new thing in human experience, and I tend to think the repeated attempts to redefine terms from other industries in our own may not be the best approach.  Whether it’s likening it to authoring, architecting, developing, constructing, etc., none of these will fully speak to the roles necessary for successful software.  So we need to keep that in mind as we think about how we further refine our industry and be willing to coin new roles as they are necessary.  But that, I suppose, could be a discussion all its own.

Wednesday, February 15, 2006 5:13:31 PM (Eastern Standard Time, UTC-05:00)  #    Disclaimer  |  Comments [1]  | 
# Tuesday, February 7, 2006

Check out my latest piece on ASPAlliance and let me know what you think!

Tuesday, February 7, 2006 9:00:23 AM (Eastern Standard Time, UTC-05:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, February 3, 2006

I just heard about TextPayMe from Steve Smith.  Pretty cool.  It's the next PayPal--you send money to people via a text message from your phone.  Plus, right now, you can win a XBox 360, get $5 for free, and I've heard that you won't get any transaction fees ever if you sign up now.  So what are you waiting for, sign up below and then text me your free $5! :-)

SignUp at TextPayMe

Friday, February 3, 2006 9:28:23 AM (Eastern Standard Time, UTC-05:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, January 26, 2006

In a comment on my post last April about SoCal's charging for a code camp-like event, Woody Pewitt, Microsoft Developer Evangelist for Southern California, acknowledges that the Florida developer community is the best in the world.

Thanks, Woody!

Thursday, January 26, 2006 8:47:32 AM (Eastern Standard Time, UTC-05:00)  #    Disclaimer  |  Comments [1]  | 

Disclaimer
The opinions expressed herein are solely my own personal opinions, founded or unfounded, rational or not, and you can quote me on that.

Thanks to the good folks at dasBlog!

Copyright © 2019 J. Ambrose Little