On this page.... RSS 2.0 | Atom 1.0 | CDF
# 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]  | 
# Friday, December 23, 2005

The latest issue of CoDe Magazine has an article called "I Object."  I wrote this piece quite some time ago as should be evident by the fact that I call the May/June issue "recent."  The content for this latest issue is not online yet but should be soon, I imagine (I just got my hard copy yesterday).  The reason I'm mentioning this is that I feel the need to acknowledge some recent advances made by Microsoft in the way of promoting object-oriented design.  Both of these were announced at PDC, after I wrote the article, and yes, I failed to revise it before publishing (my bad).

First, Microsoft announced the new Language Integrated Query (LINQ) technology.  I think this is an absolutely huge step forward in easing some key difficulties now present for OO development in .NET, as I previously discussed on this blog.  Whether or not this is a real innovation (I've heard something like it has been present in other languages/platforms), I give Microsoft big kudos for bringing it into the .NET family as only they could.

Second, Microsoft released the public preview of WinWF.  Just the other day, I posted an article discussing this technology and its importance.  While this is not directly an OO thing, it does (obviously) use OOD, and it adds a new facet to our development that is focused on processes.  In addition, its activity-centric architecture has a similar potential to OOD in that it lends itself to being highly composable and reusable.  Together with good OOD, this technology could have a dramatic impact on software development.  And I give Microsoft further kudos for being bold enough to bet on it; I think, for better or worse, that they are the only real singular force that has the power to shape our industry. 

I should also mention that their DSL tools and, in particular, the class designer are a step in the right direction to help make good OOD easier.  I failed to mention that in the CoDe article, and I should have.  The folks in the dev division at Microsoft are some of the brightest in the industry, and it's good to see that they're starting to focus more on OOD and other key aspects of development that can evolve business application development in a positive direction.

Friday, December 23, 2005 7:30:57 AM (Eastern Standard Time, UTC-05:00)  #    Disclaimer  |  Comments [2]  | 

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