Tech-ed 2009 - Day 3
A few fragile heads this morning (by virtue of the TechFest party the previous night); being a girly-swat I didn't go too hard-out and wasn't too sour (although a bit tired). Sorry if that sounds too lame for you - I'll try and get myself arrested next time.
ARC203 Services and Complexity with Roger Sessions
I almost didn't go to this session and it turned out to be one of the best of the whole Tech-Ed.
Roger is an excellent speaker - easy to listen to, and a deep knowledge of his profession. The basic subject of his talk was around reducing complexity in a way that also measurable.
He started with his driver - which was research which claimed that %60 of the money invested in IT projects was invested in "at risk" projects. He estimated that this cost the globe $6.5 Trillion USD a year, or New Zealand $21 Billion NZD a year. (Now, you'll have to bear with me, I made these note in haste and they aren't complete - so don't quote me on exactly who said exactly what - so long as you get the drift.)
In terms of trying to tackle this problem, Roger is thinking along the lines of managing (i.e: reducing) complexity.
He started off quoting Robert Glass:
"For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity." - (Fact 21 from 'Facts and Fallacies of Software Engineering', by Robert Glass)
Roger argues (quite convincingly, IMHO) that we can apply this to services (i.e.: SOA):
"For every 25 percent increase in the number of service connections or business fucntions in the service, there is a 100 percent increase in service complexity."
The next point Roger made was that when presented with two different architectures - how can you decide which is the better one? His answer was to look at complexity. Roger moved on to Birds Formula* and how by using this formula we can measure an architecture based on the number of services and connections. So, having establishing a way to measure an architecture based on it's complexity we can now compare two architectures and see which is better / less complex. The result is a number which Roger calls the complexity rating of the architecture in "Standard Complexity Units" (SCUs).
* I would reference this but it hasn't been published yet - how's that for bleeding edge! :) Roger said he'll let me know when they do, and I'll put an update out then.
The formula is basically (forgive the gif, but it's not easy to write in plain text):
[Small note; the gif was supplied by Roger himself - thanks Roger :) Check out his blog.]
Roger then moved on to Bells Number and the concepts of partitioning and set theory (oi!), and his idea of Simple Iterative Processing (SIP). The concept here is fairly straight forward, basically we're looking for synergies between functions - functions that naturally belong together and which form a simple cohesive service:
- Decompose the problem domain into a "universe of elements" (a list of business functions). Note: This list should still be recognisable to the business.
- Start with a specific function (for example: "Ask to Borrow") - and put it into a service ("Service A" will do for now).
- Move to the next function and compare it with the existing one - are they synergetic? Does one of them require the other? If so add the second function to the appropriate service.
- Repeat for every function, and add the function to the appropriate service (or create a new service) as required. If you've partitioned the functions correctly you'll find that you'll only need to compare the new function with one or two of the existing functions in the service.
- Once you've finished, work out the SCU.
You can repeat the process again if you want if you're not happy with the architecture - or use it on old or existing architectures; then you can compare the SCU scores. In the talk Roger gave he used a fictitious example of the architecture for an inter-library loan agency. The first architecture (which I guess we could call a business architecture) looked plausible and had a SCU score of around 1056. He then presented a second architecture derived via the SIP process which was massively less complex with an SCU score of 366 (approx).
The great thing about SIP is not only the great results and practical application, but also the fact that it's repeatable and reproducible.
DEV205 A Tour of CodePlex with Sara Ford
I've always wanted to know more about CodePlex but just never found the time; Sara's session was just what I needed, and it's always nice hearing from someone who is both openly passionate about what they do.
Following her talk, I'm pretty much convinced I'll release the open-source version of Morphfolia on CodePlex - hopefully within the next few weeks.
Sara spoke on a number of topics related to CodePlex including: what open-source is, how the site works, how they develop the site and so on.
You'd think everyone knows what open source is, right? Maybe it's only us Microsoft supporters who don't? Apparently the Wikipedia definition of Open Source is updated 30 times a month - so maybe it's not as clear cut as some people would have us believe.
My personal view, which appears to have been mistaken, was that open source was synonymous with community; i.e: you couldn't go open source without having people contribute. This is an issue for me (at the moment) as I just don't feel I have enough time to dedicate to a community - that might take on a life of it's own. Sara said that this wasn't the case, the "benevolent dictator" concept is fairly common and accepted.
License wise, most people (around %38) use the Ms-PL and about %22 use the GPLv2 (which is probably what I'll move to). Check out these links for more info: Understanding Open-Source Licensing and How to make money from open source / open source revenue models. (Tip of the hat to my friend Amir)
CodePlex is developed using an agile methodology (Scrum I think - but don't quote me!); Sara runs development in three three-week iterations: teh first two iterations are for new features and the third iteration is dedicated to bug fixing and polishing (no new features). At the end of the three week iteration the code is released to the test team, and deployment into production (if successful). The testing and deployment run along side the development iteration, so over the whole team they keep up a nice steady rhythm; the developers basically roll into a new three week sprint while the testers test the 'previous' sprint.
CodePlex itself is scaled out on 10 TFS servers, and as of July 2009 hosted 160 million lines of code and 124 million files (of which approx %70 were C# files). If you're interested in more stats behind CodePlex, see CodePlex Turns 3 years old; Breaks the 10,000 project mark.
WUX309 ASP.NET MVC - End-To-End with Jeremy Boyd and John-Daniel Trask
This turned out to be my final session for the day; Jeremy and John-Daniel gave us a closer look at the ASP.NET MVC framework. Thier session was an excellent dive into the code and a good way of getting aqainted with the framework if you're new to it.
I won't give an explaination of what the ASP.NET MVC framework is here, so go away and get yourself aqainted.
According to Jeremy and JD, Route Management and Model Binders are two key concepts you'll want to look into.
Here's a short list of other points you might want to bear in mind:
- A good reason to use the ASP.NET MVC framework is that you get absolute control over the HTML sent to the browser and the framework offers a lot of extensibility points.
- There is currently a relative lack of control libraries (although that is starting to change).
- When posting data you may want to consider implementing your own IModelBinder, (this might help). From what I can remember (doh, not enough notes) you can use this to bind directly to custom types (classes you have defined).
- You maight also want to look at implementing your own View Engine or Controller.
- Consider restructuring the Action pipeline (check out ASP.NET MVC Action Filters).
|