tag:blogger.com,1999:blog-318547012024-03-13T21:27:40.719-07:00Neo Diemtechno-babble from the throes of large-scale custom application development.Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.comBlogger105125tag:blogger.com,1999:blog-31854701.post-48415982177671195002016-11-09T08:13:00.000-08:002016-11-09T08:13:13.862-08:00Sprint Planning Is RidiculousAgile is great.<br />
<br />
Watching Scrum sprint planning is silly. It is hilarious to watch a few engineers with no knowledge of the larger system or technology dragging the entire group down a rabbit hole about nonsense ideas and misconceptions.<br />
<br />
Generally speaking, the ambient benefits of ensuring that everyone is on the same page are typically worth having a lengthy slug-fest in which everyone gets to submit the group to their ignorance. Personally, I love getting my questions answered in a high-bandwidth way. Having to do it front of an audience who could care less isn't as fun.<br />
<br />
Going beyond having well-written stories and foundational knowledge across the team that is a prerequisite, there is a certain pattern in the conversations that a smooth team naturally follows which mitigates the risk that spring planning beomes a morass. Most importantly is identifying technical patterns and practices that the group will pursue with priority.<br />
<br />
When we consider that there are lots of ways to model a data structure or class definition we have to allow for each contributor to bring their own preferences to the effort of creating a whole solution. What we would like to ignore is that the choices of one will impact the many. The pattern that a data modeler prefers will definitely drive the implementation of the contributor responsible for the services or the user interface. In our self-centered world view we like to pretend that we can use Separation of Concerns or isolation patterns and that will remove our interdependency. This is fallacy. Just because you say you prefer SOA or hiding implementations behind RESTful interfaces doesn't mean your choices for data structures, invocation patterns, and state management won't impact the work required in my client or integration service.<br />
<br />
And don't get me started on how ludicrous planning poker is for actual estimation. Don't misunderstand me. Asking everyone for their opinion of the size for a thing is an quick and effective way to uncover misunderstandings and misaligned expectations. But the idea that the wisdom of the group is better at determining an actual estimate is patently wrong. The issues with group think are many and well understood. Assuming they don't apply to software development is near-sighted and ignorant. So definitely have a round of planning poker and find out who isn't aligned with what the group thinks needs to happen. Then listen to the contributor who will do the work on how long it will take. Allowing a contributor to 'compromise' to group allows them to skirt accountability for estimating accurately, making solid commitments and keeping them. And if you can't ask for accountability and hold people to it, what is the incentive to get better?<br />
<br />
Basically, the group rituals have their place and some distinct advantages. But at some point, you have to shift from low-bandwidth group think into high-bandwidth individual performance. Effectively making this transition is the hard part and a common point for many to abandon Agile and Scrum. This is all to reiterate that "Common sense is uncommon" and if something has more than one person accountable, then no one is accountable.Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com1tag:blogger.com,1999:blog-31854701.post-71668490404523054982016-06-29T11:32:00.000-07:002016-06-29T11:32:01.385-07:00GigJam: Not Just Another ToolIf you haven't checked out <a href="https://www.microsoft.com/gigjam/" target="_blank">GigJam</a> from Microsoft you're behind the curve. Bots and messaging plug-ins might be the flavor of the month, but they're just different flavors. Gigjam really is a new approach to how you collaborate. Check it out.Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-68913059422362348472016-01-28T15:57:00.003-08:002016-01-28T15:57:57.267-08:00Parse Shutting DownIn case you haven't heard, <a href="http://blog.parse.com/" target="_blank">Parse</a>, the well-known Database-as-a-Service provider is shutting down.<br />
<br />
Details <a href="http://blog.parse.com/announcements/moving-on/" target="_blank">here</a>.<br />
<br />
As one of the easiest and cost effective ways to stand up a back-end database, this will have some big repercussions across the landscape. Which makes you wonder what kind of leading indicator this might portend. In any case, it definitely speaks volumes to how unrealistic our expectations about the costs involved with running any derivative of SaaS product have become.<br />
<br />
Hold on to your butts!<br />
<br />Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-22452197234114231452016-01-08T11:04:00.001-08:002016-01-08T11:04:27.104-08:00It's Autonomous Movement. You're Welcome.Back in 1995 I gave a talk on the next big step that would advance technology non-incrementally. The prediction was that nearly free, ubiquitous access to high-speed, nearly infinite storage would be the trigger. This was framed in the context of Moore's Law that processing power would increase, become cheaper, and increasingly smaller forms. For all that to usable, we would need storage to match. The aggregate of those would allow for rule and pattern algorithms to see a step-function increase in capability which would unlock natural language processing and a veritable flood of sensory inputs, orders of magnitude beyond what was available then.<br />
<br />
And that is precisely what we have seen.<br />
<br />
During a recent talk, I was asked to update my predictions and I was shocked to realize that I had completely forgotten to publish any of my writings on the subject. I'll get more into the detail in subsequent posts but the short form is that <b>autonomous movement</b> is the next non-incremental technical revolution for mankind.<br />
<br />
Imagine when you can take a box and connect it to frame that provides sensor information and locomotion. Right now, imagine that box is the size of a large piece of luggage and needs significant amounts of power and cooling. But that box that take inputs from gps, stereo cameras, thermal imaging, infrared beacons, wifi and bluetooth signals, lidar and so forth, and provides outputs that allow the frame to be aware of its location and control locomotion from any point to any other point. While movement is underway the box analyzes the sensor inputs to be constantly aware of its location and adapt to roads, obstacles, people, signals, signage, and other conditions as it independently controls movement using the locomotive capabilities to reach a destination. This is what a self-driving car would need to do to be self-driving.<br />
<br />
It is also what a self-driving semi-truck would do. Or a bus. Or a tractor. Or a delivery van.<br />
<br />
Now imagine that miniaturization continues and this very large box becomes a very small box. It becomes small enough to fit inside the remote control car your child might play with. The cameras and sensors and batteries and the box itself only take up the space of a large shoe box.<br />
<br />
If you could put this box and sensors and power in a small box, then you could use it not just for making a car autonomous. You can now make a shopping cart autonomous, or a camera that represents you remotely, or a mailbox.<br />
<br />
Every situation in which something must physically be moved as cargo (including humans) can now be moved by independent locomotive devices with these boxes and sensors. Some frames are big like the trailer trucks that hog the road today. Some are small like the size of stove or refrigerator. Some carry one or two people, some carry dozens of people. Some large ones, only carry small ones, like a fleet of small flies on the back of a rhino. The big carrier frame would zip from the warehouse to your neighborhood and offload a bunch of little frames that dart around offloading their cargo into receptacles or awaiting humans to come unlock their doors and remove their packages. The trash bin on the corner wakes up when it is full and takes itself to the processing center, replaced by an empty bin that moves itself out of storage; all without human intervention. Why have a store when I can request that the produce counter come to my office? I pick through the grapes and broccoli making my selections which I deposit in my personal box which will be waiting for me when I get home. We already see the push to online and personalized delivery, imagine when you can take humans and the cost of moving and storing physical goods completely out of the equation.<br />
<br />
So anyone in the business of moving things or people, or selling physical items from a physical location, or delivering anything for anyone, take note. There is a clock ticking on your industry. After all, the big box that fits in the car is only a few years away. And once we have the box, the only challenge is making the box smaller. And making the box smaller is vastly easier than getting the box right the first time.<br />
<div>
<br /></div>
Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com2tag:blogger.com,1999:blog-31854701.post-9459240479235679922015-03-02T12:07:00.001-08:002015-03-02T12:07:45.571-08:00Want? Need.<div>Brilliant idea. I'm all over this.</div><div><br></div><div><a href="http://techcrunch.com/2015/03/02/podos-camera-turns-any-surface-into-a-photo-booth/">http://techcrunch.com/2015/03/02/podos-camera-turns-any-surface-into-a-photo-booth/</a><br><br></div>Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-17135357661966819502013-11-18T07:29:00.000-08:002013-11-18T07:29:40.299-08:00Why Spend So Much?<div dir="ltr" style="text-align: left;" trbidi="on">
I'm helping out with a strategy for an enterprise. They've got less than 10 thousand people, but they've grown through mergers and acquisitions. Which means they've got about 100 different organizations that are scattered around the globe who are driving the 10 billion or so in revenue they earn. With all the fragmentation and overhead redundancy they are spending a ludicrous amount on IT infrastructure. My question is "Why?"<br />
<br />
Being a Microsoft veteran and deeply wedded to their stack on many levels doesn't stop me from wondering, why on earth anyone is doing anything in-house, on-premise. More than 10 years ago, I was helping companies move to virtual IT infrastructure management with British Telecom and MCI. Have we learned nothing?<br />
<br />
Here are some anecdotes about how obvious it should be to pick better options but how much waste there is in the enterprise.<br />
<br />
<b>Cloud Storage</b><br />
Why is anyone paying for box.net? These guys are parasites taking advantage of the fact that companies are stupid. A typical seat for an enterprise runs about $200/year. For a small user base of around 2k people you'll kick them $500,000. <i>For disk space.</i> When that same company gets a similar amount of per/user storage through their enterprise agreement from Microsoft as part of SkyDrive for free. If this company woke up and moved to Google they would get even bigger storage packed into an enterprise agreement that costs less, and the storage would still be free! The big boys get that storage is the table stakes so you will buy their apps like email. Just being willing to properly leverage tools they already have would save this company hundreds of thousands of dollars a year for this one thing.<br />
<br />
<b>Cloud Print</b><br />
Moving to cloud printing from Richoh, Xerox, or (gasp?!) Google means a typical company would get printer management basically for free. If you are leasing hundreds of printers, then managing and printing through the cloud is just table stakes. If you are small company, just buy or lease cloud-print enabled printers and you can ditch the local print server completely. One company I advised just ditched a $2 million a year contract. Additionally, by upgrading to cloud-printers they now have 30% more printers for half of what they were spending to capitalize old hardware.<br />
<br />
<b>Identity</b><br />
To keep this example going, the next thing to get off-premise would be identity management. Again, I have to go with Google on this one who has an end-to-end offering that works with all their other products with virtually no configuration. Or get some hosted Microsoft Exchange and you'll get an AD for free just like Google. Again, table stakes to pay for the real products that are going to pay for anyway.<br />
<br />
And this list goes on with servers, scanning, accounting, web content, etc. A really interesting and recent example is with hardware like phones. A company I work with spends more than 10 million a year on communication hardware. Everyone gets a mobile phone, laptop, desk phone, and there are projectors, cameras and speaker phones in every conference room. Compare that to a similarly sized company I just advised who lets employees bring their own phones, leases laptops, and has Chromebooks with Chromecast in the conference rooms. They use Office Communicator and Google Hangouts with integrated AD. Everyone is available through managed Google Voice numbers that route dynamically to laptops, conference rooms, and mobile phones. They video conference using the built-in hardware in Chromebooks and anyone can use the big LCDs in the conference rooms via Chromecast. Want to collaborate with someone? Sit at their desk and pull up your desktop on their laptop or just send your desktop to their display virtually. They have more ways to get in touch, easier video conferencing, and most importantly save almost 10 million dollars a year in hardware, cabling, and other infrastructure. <i>(Note to self: I really should look into getting paid a percentage of what I can save a company.)</i><br />
<br />
There are tons of other examples of how using the right tool for the job saves you money. Don't let the niche players sucker you into spending more than you need. If you are an enterprise, you probably have what you need and don't realize it. Need help, just ask.<br />
<br /></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-55169382306079149202013-09-09T13:58:00.001-07:002013-09-09T13:59:14.322-07:00Enterprise Indexing<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
<div class="MsoNormal" style="margin: 0in 0in 0.0001pt; text-align: left;">
Recently I was asked for my opinion on the subject of enterprise indexing. This is usually lumped in as part of the enterprise search space but there are quite good reasons that indexing is being treated more as a first class citizen these days. Since I made time to write some thoughts down, however crudely, I figured I might share it here.</div>
<div class="MsoNormal" style="margin: 0in 0in 0.0001pt; text-align: left;">
<br /></div>
<div class="MsoNormal" style="margin: 0in 0in 0.0001pt; text-align: left;">
<blockquote class="tr_bq">
<b style="background-color: rgba(255, 255, 255, 0);">Summary</b><br />
<span style="background-color: rgba(255, 255, 255, 0);">Enterprise indexing is an aspirational goal but has generally found to not be practical for enterprises of significant size. Focusing on isolated but consistent patterns for indexing individual organizations within the enterprise will generally unlock more value and gain substantively more adoption. I have found the generally accepted approach is to begin with this isolated indexing of individual organizations. This is seen as a first step on the journey to enterprise indexing. We just don't mention it's a never-ending road.</span></blockquote>
</div>
<div class="MsoNormal" style="margin: 0in 0in 0.0001pt; text-align: left;">
<br /></div>
<div class="MsoNormal" style="margin: 0in 0in 0.0001pt; text-align: left;">
<b style="background-color: rgba(255, 255, 255, 0);">Opinion<o:p></o:p></b></div>
<div class="MsoNormal" style="margin: 0in 0in 0.0001pt; text-align: left;">
<span style="background-color: rgba(255, 255, 255, 0);">Using a search index to surface data and make it widely and easily accessible is an imperative for any business. However, “enterprise indexing” as we typically understand it, proves to be mostly impractical. There are three primary reasons for this impractically.</span></div>
<div class="MsoNormal" style="margin: 0in 0in 0.0001pt; text-align: left;">
<span style="background-color: rgba(255, 255, 255, 0);"><br />
</span></div>
<div class="MsoNormal" style="margin: 0in 0in 0.0001pt; text-align: left;">
<span style="background-color: rgba(255, 255, 255, 0);">The first is because the vast majority of corporate data is sensitive by nature. Consider how many business systems actually allow open access across the enterprise. There are many reasons for this information containment, most of which are immovable.</span></div>
<div class="MsoNormal" style="margin: 0in 0in 0.0001pt; text-align: left;">
<span style="background-color: rgba(255, 255, 255, 0);"><br />
</span></div>
<div class="MsoNormal" style="margin: 0in 0in 0.0001pt; text-align: left;">
<span style="background-color: rgba(255, 255, 255, 0);">Moving beyond the sensitivity concerns to the second point, it is also understood that the vast majority of corporate data is useless without significant context. Consider how many acronyms, slang words, abbreviations, and specialized definitions exist in the typical organizational vocabulary. Even given the relatively new technical ability for tools to automatically discern the presence of this context does not address the massive effort to create correlations and harmonize these contexts between organizations. For example, an organization 1 that serves the public and is served by another organization 2. They both refer to clients/customers but one means the public and one means employees. This is just a simple example, what if sometimes organization 1 served employees and public? These are real issues that compound the problem of context.</span></div>
<div class="MsoNormal" style="margin: 0in 0in 0.0001pt; text-align: left;">
<span style="background-color: rgba(255, 255, 255, 0);"><br />
</span></div>
<div class="MsoNormal" style="margin: 0in 0in 0.0001pt; text-align: left;">
<span style="background-color: rgba(255, 255, 255, 0);">Lastly, organizations operate in silos for practical reasons as well as sensitivity (ie. the need to govern the flow of information). For example, consider how many forecasts and versions of forecasts roll up in the typical capital planning process. Without the ability to understand what data is correct or accurate when the volume is hierarchical and broad, the reliability of the index for answers goes way down and therefore the relevance to users and therefore adoption.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin: 0in 0in 0.0001pt; text-align: left;">
<br /></div>
<div class="MsoNormal" style="margin: 0in 0in 0.0001pt; text-align: left;">
<span style="background-color: rgba(255, 255, 255, 0);">Having expounded on the challenges of doing it for an enterprise doesn't excuse the necessity to do within organizations inside the enterprise. Every organization across an enterprise should utilize consist toolsets and processes for indexing and searching as a first step. Only when this is happening will an enterprise index have the context to provide relevance and security to the information being indexed. As the patterns to publish and consume matures, information quality can begin to mature which may ultimately allow for these isolated indexes to be aggregated and provide a wider scope.<o:p></o:p></span></div>
<div class="MsoNormal" style="margin: 0in 0in 0.0001pt; text-align: left;">
<br /></div>
<div class="MsoNormal" style="margin: 0in 0in 0.0001pt; text-align: left;">
Because of the complexities, the typical consultative answer is to start by rolling out these "enterprise" index and search tools to one organization at a time and then to bring others on incrementally. While an idea of merit and suitable for smallish enterprises or when the desire for information transparency is actually quite shallow, this typically hits a few harmonizing and integration snags and the effort stalls. For example, failure to provide necessary context makes results unusable to users so adoption stagnates. Or a sensitivity issue is uncovered and the whole thing is scrapped for being too risky. And so on and so forth. If it were a consistent and ongoing part of your enterprise strategy and operational initiatives for information management it can easily thrive. This requires that it be treated as an on-going operational concern that requires sustained investment and effort. Enterprises that don't acknowledge this and embark with their eyes open and clear expectations will inevitably give up. Which is pretty much the current state for most of them. With a little digging you find this is true even for those who say they do it well. The true user adoption and penetration numbers, the actual productivity metrics rarely tell this same story.<br />
<br /></div>
</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-65911402282700866652013-08-26T10:24:00.000-07:002013-08-26T10:24:20.050-07:00Seriously... One Third<div dir="ltr" style="text-align: left;" trbidi="on">
There has been much hubbub and ado about the announcement that Ballmer is stepping down from Microsoft. Although I don't understand why it should be a surprise to anyone that a successful giant nearing the age of sixty with billions of dollars would want to stop working and relax on a beach somewhere. But I digress.<br />
<div>
<br /></div>
<div>
The funny thing to me was not all the "Is this the end?" or "Microsoft failed" commentary. That type of silliness will always persist because people are adversarial, petty, and generally not very bright. Instead I laughed every time it became clear that these *ahem* journalists or editors didn't really have a very clear picture or had skipped the non-obvious research.</div>
<div>
<br /></div>
<div>
For example, on TechCrunch there was a call to shakeup the Microsoft board. Which I fully understand and quite frankly agree with. But reasons were just silly. In one case the mention was made that even with the failure of the latest hardware releases, Microsoft should still be okay because they have 1 or two other businesses that produce some revenue. That's funny.</div>
<div>
<br /></div>
<blockquote class="tr_bq">
<ul style="text-align: left;">
<li>One third of the worlds telephone traffic is driven by Skype. </li>
<li>One half of all server revenue is driven by Windows Server.</li>
</ul>
</blockquote>
<div>
<br /></div>
<div>
Don't get me started on XBox, the game console that sold more units this holiday than any other manufacturer.</div>
<div>
<br /></div>
<div>
Has Microsoft been sitting back pushing out products at a sluggish pace? Certainly. Are they behind on the innovation curve? Absolutely. But just because revenue for consumer devices in the midst of bubble has outstripped corporate spending, don't discount the ability of corporate spending to catch up. Don't for a minute ignore that holding those patents that bring in big bucks every time an Android sells is negligible. If you want to make a case of demise, it has to be more than top-line revenue. It's about explaining motivations, potential and positioning.</div>
<div>
<br /></div>
<div>
Does Microsoft have this? Who knows. I'm hardly a proponent and ardently a critic of their bloated, boorish, and bland offerings these days. I just get agitated when I see one-sided conversations, and shallow analysis masquerading as some deep insight.</div>
</div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-34761083596773271022013-08-02T10:00:00.000-07:002013-08-02T10:00:07.610-07:00Data About Food<div dir="ltr" style="text-align: left;" trbidi="on">
I've just spent the last many days reviewing, testing, quantifying, validating, and otherwise taking the measure of the various data sources that exist for and about...food.<br />
<br />
The USDA gives great nutrition data and a sampling of volume-metric data for a pretty wide swath. But then you have manufacturers and brands and alternative nutritional information. And you have categorization and ingredient discrepancies, all manner of portioning, form, and packaging options. And so on, and so on.<br />
<br />
Not surprising some of the best food data comes from the online shopping hubs and support establishments who want to make it easy for you to buy through their channels. After all, who shops online without looking at pictures, even if it is just for a bottle of ketchup or can of soup?<br />
<br />
As typically arises in these scenarios, the categorization schemes they each favor isn't particularly overlapping or supportive. They certainly aren't designed to co-exist as they have a vested interest in keeping you in their garden of data. So you go with Option A with 10k foods or Option B with a partially overlapping 50k of foods. Maybe Option A is better organized with better data and easier access. Option B might be much more expensive or just have no reliable categorization scheme. Choices, choices.<br />
<br />
In an enterprise we would call this a Master Data Management problem. In the real-world, it's just business. Good thing I know a little about addressing these MDM issues in really big enterprises. How to rationalize 10's of thousands of foods ain't no thing if you've got the right patterns and the discipline to do a little wrangling. I just needed to wrestle this foundation to the bedrock so that now I can take on much more interesting concerns. Like merging some hardcore analytics, massive datasets, and some truly sick algorithms all towards helping people get and stay healthy.<br />
<br />
Let me finish this glass of scotch and I'll tell you more about the coolest new stuff we are working on in connected health...<br />
<br /></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-80737708726346292182013-04-23T13:17:00.000-07:002013-04-23T13:17:00.307-07:00Change and DataIt takes me a little by surprise how often I talk with people who are trying to make a change but who have no idea how to go about accomplishing it. Invariably, they aren't nearly as successful as they would like and I blame it squarely on their lack of deliberation.<br />
<br />
If you want to improve something, you first need to know what the current situation is like. Let's say you make tires and you think you'd like to make 5 more tires per week. If you are only making 10 tires a week, then expecting to make 5 more might be totally unrealistic. Similarly, if you are making 5000 per week, why would adding 5 be such a challenge? Figuring out the current situation requires some kind of measurement. <b><i>You have to count something</i></b>; you have to quantify some aspect of what you want to change.<br />
<br />
Believe it or not, figuring out <i><b>what </b></i>to measure is the hardest part of the whole improvement process. If you serve meals in a restaurant, it is useful to know how many people you served. But it is more helpful for efficiency to know how long it took you to serve them. If it is satisfaction you are after, measuring how long people had to wait for a table is more influential than just knowing how many people waited.<br />
<br />
Similarly, it isn't always just about measuring <b>one thing</b>. It is about measuring the relationship between the many things that make up the process or behavior you are trying to change. If you don't start to beak out <i>why</i> the measurements are turning out the way they are, you won't necessarily be able to extrapolate what any particular change might do to the measurements in the future.<br />
<br />
If you want to change something, start by measuring. Once you know what to measure, ask why the measurements have turned out that way. Only then can you start to theorize about the impact of a potential change. Often it is while figuring out the <b><i>why </i></b>that you come across new ideas for how to change the <b><i>what </i></b>as well. As you propose and then implement changes, having a process in place to measure will give you the feedback you need to see if your changes are having the desired effect. This feedback loop is how change become more than just a one-time event. Adding this consistent loop of measuring, analyzing, hypothesizing, changing, and then repeating is what drives effective change. Without the measuring you don't know where you are starting from and therefore you'll probably not realize when you will arrive or recognize that you'll never arrive. You'll be one of those people always busy with activity but not making any progress.Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-46857068598182412572013-03-26T11:21:00.001-07:002013-03-26T11:40:51.491-07:00Embrace The Pain<div dir="ltr" style="text-align: left;" trbidi="on">
There are some situations you find yourself in that simply have no good resolution. Circumstances sometimes make it that you are choosing the lesser of two evils. Yes, this is a common cliche but what isn't common is how you can sometimes use these situations to your ultimate advantage. Let me explain.<br />
<blockquote class="tr_bq">
Getting to pain as quickly as possible is a motivator for success.</blockquote>
Driving adoption or gaining mind-share is always a challenge. This is because we aren't always aware of our baggage and assumptions. We get complacent and just accept that things are going to continue forward in whatever way they have been in the past. This stops your contributors, decision-makers or constituents from taking action or seeing a way forward. They see the unknowns in the future as risky and uncomfortable compared to the situation they have come to know, regardless of the discomfort or short-comings of that circumstance.<br />
<br />
To drive activity or reaction, you need a pain to shock the system. You need people to be internally motivated to confront their fear head-on. Embracing the need for true change must come from within. While you can try and force behavior, you can't force someone to accept your perspective. You can, however, influence them to evaluate their own perspectives which can have the similar result of allowing someone to embrace the need for change.<br />
<br />
We can leverage this need to make up our own minds as a key to influence. Allowing others to feel the true weight of their own choices is often enough to help them see that a change is necessary. If you realize your people are in this situation, you can help them make up their minds quicker by allowing the short-comings and discomfort of their situation come to light. Which is why we see that getting to pain quickly is a great motivator. This is a corollary to the tenet that if it is <a href="http://blog.liquidperspective.com/2009/02/3-tenets-to-being-better.htm">possible to fail, fail as fast as possible</a>.<br />
<br />
Some ways you can help people get to pain is by defining metrics you actively track, making people write down issues instead of just verbally complain, and keeping your mouth shut when they take risks or make bad decisions against your advice.<br />
<br />
Some things to keep in mind are not saying I told you so when things fall apart, staying ambiguously neutral when they try and drag you into their mess, and make sure the lines of accountability and expectations for communication are very clear.<br />
<br /></div>
Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-77578118540485334812013-02-15T11:13:00.001-08:002013-02-15T11:13:17.741-08:00AmazonIn case you weren't paying attention:<br />
<br />
<blockquote class="tr_bq">
<ul>
<li>Amazon went from 3 categories of items it sold in 1997 to 16 categories in 2010.</li>
<li>Amazon's market share represents <b>one-third<i></i></b> of US e-commerce sales.</li>
<li>It only took <i><b>120 days</b></i> for Amazon to go from no presence to the largest online seller of music.</li>
</ul>
</blockquote>
You're welcome.Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-26019010717828338902012-12-14T09:52:00.003-08:002012-12-14T09:52:25.104-08:00Messy SOCS<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-pdGPgzGkWMs/UMtnPmjegvI/AAAAAAAAR0w/mA4eSgZV5Oc/s1600/news_cable_mess_03_full.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="http://4.bp.blogspot.com/-pdGPgzGkWMs/UMtnPmjegvI/AAAAAAAAR0w/mA4eSgZV5Oc/s1600/news_cable_mess_03_full.png" /></a></div>
I was helping one of my teams get unstuck and it took five minutes to realize that their issues was not <i>knowledge</i>, it was <i>data</i>. The circumstance is usually the inverse so let me explain what I mean.<br />
<br />
This team is operationally very mature. They have solid, documented, processes, qualified and competent people and are really running very smooth. The issue is that almost nothing is written down and even less goes through any formal evaluation process regularly. In the heads of all these wonderful workers are the ways and means, the reasons and rationale, and the detail behind decisions. The know a lot, but they can't reference very much. They may make good decisions, but have little evidence that survives the decision-making process. This means the organization, while mature, is actually quite frail. They are deeply impacted by personnel changes and have substantial exposure to risks and accidents.<br />
<br />
To help get a handle, we've been developing a Situation Report. There are lots of names for this type of information, lots of ways to assemble, and lots of examples. I personally prefer the SOCS approach.<br />
<blockquote class="tr_bq">
<ul>
<li><b>S</b>ituation - What are the facts, components, processes, and other influential elements that comprise the situation you find yourself. For information technology this is often a combination of the 3 P's (People, Process, Platform). </li>
<li><b>O</b>ptions - What do you know about the alternatives? What have you evaluated? What needs to be evaluated?</li>
<li><b>C</b>onsequences - Assuming status quo, how will the situation change? For actionable options, how will the situation change?</li>
<li><b>S</b>olutions - What actions are needed to evaluate or realize the options? What timeline, what risks?</li>
</ul>
</blockquote>
<br />
This is one of those glaringly obvious ways to collect and/or present information that is so clean as to be easily overlooked. Give it a shot the next time you need to make sense of mess.<br />
<br /></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-21288459502989013472012-11-01T10:58:00.000-07:002012-11-01T10:58:33.369-07:00TFS Preview<div dir="ltr" style="text-align: left;" trbidi="on">
I'm just going to say it. The TFS Preview is the smartest thing from Microsoft in quite a while. Well, since they started offering free virtual servers so engineers could train and experiment with the platform, anyway.<br />
<br />
It's like what [Github/bitbucket/insert crappy open source code repository of choice] and [insert project management software of choice] would be if they grew up and had a really cool kid that didn't suck.<br />
<br />
Now if they can just get make a phone with the reliability of an HTC and camera with optics better than an iPhone, we'd really be cooking...<br />
<br /></div>
Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-31854701.post-10541772269513331842012-06-18T09:37:00.001-07:002012-06-18T09:37:57.844-07:00Acronyms<div dir="ltr" style="text-align: left;" trbidi="on">
Acronyms are amazing things. I have tons and in my industry they seem to be everywhere. In reality most of them are quickly forgotten and of limited value beyond shortening the conversation.<br />
<br />
However there are a couple of favorites that are indispensable for helping ensure critical thinking and completeness. For example:<br />
<br />
<blockquote>
SMART - This relates to setting goals and describes the attributes you should ensure each goal encompasses.<br />
<ul>
<li><b>S</b>pecific: details to remove wiggle room when determining if the goal was met</li>
<li><b>M</b>easurable: if it can't be measured, how will you know if you accomplished anything?</li>
<li><b>A</b>ttainable: don't set yourself or others up for failure</li>
<li><b>R</b>esults-Oriented: it helps to think in terms of an outcome or future state so others can support you, it also gives you a benefit to anticipate</li>
<li><b>T</b>ime-Sensitive: everything needs a timeline so we have a sense of urgency and more importantly know when to declare success or change tactics</li>
</ul>
</blockquote>
<br />
<br />
and I've recently added another one to my short list:<br />
<blockquote>
FACT - This relates to the quality and integrity of data or intelligence.<br />
<ul>
<li><b>F</b>it-for-purpose: does it apply, can it be used, is it appropriate?</li>
<li><b>A</b>ccurate: how reliable and consistent is the information or the source?</li>
<li><b>C</b>omplete: are there other inputs that could color the interpretation? does the data stand on its own?</li>
<li><b>T</b>imely: how up-to-date is the information, and can age impact the interpretation or usefulness?</li>
</ul>
</blockquote>
I'm sure there are plenty others that you use, and I've a few more on my list I'll share later.<br />
<br />
<br />
<br /></div>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-24078407006817938252011-10-04T15:32:00.000-07:002011-10-04T15:37:58.142-07:00Don't Get Bullied<img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 240px;height:240px;" src="http://2.bp.blogspot.com/-ano0caszDVk/TouJAvWuaTI/AAAAAAAAK60/T695bB5D7o0/s1600/dodgeball.jpg" alt="" border="0" /><br />
In dealing with multiple groups that have sometimes conflicting agendas, and almost always conflicting value systems, confusion can reign. After one such recent encounter, I wrote an opinion piece to help a beleaguered business analyst fend off some bullying by some techie types. Here's a sanitized version of that email:<br />
<br />
<blockquote>Generally speaking, I notice people tend to either speak too high level or too detailed. It usually a function of the point they are trying to make that coincides with their particular opinion. ;-)<br />
<br />
Getting an accurate answer without excruciating detail can often be achieved through a discussion about groups of attribute behaviors (which can be called a class). Regardless of many attributes or few, attributes can usually be grouped into a manageable number of groups by their behavior. These groups (or classes of behavior) are much easier to manage because they are specific, distinct, and typically much fewer in number. Any attribute under discussion can then be placed in a group, which means we don't have to know about every specific attribute up front, or even be correct about which attribute is in which group. By talking about these groups (or classes of behavior) we can all stop confusing each other with overly specific or overly general examples.<br />
<br />
So what defines these groups (or classes of behavior)? The location and process by which an attribute is created or maintained is usually a good starting point. For example, some attributes (say product SKU) will come from ERP and cannot be edited outside of the ERP regardless of how it is consumed downstream. All attributes that come from and are maintained only within ERP share the same behavior and are therefore part of the same class (they are in the same group). For simplicity, we can consider these <b>primary</b> or <i>core</i> attributes.<br />
<br />
If we further consider that some attributes will need to be created and maintained only by a downstream consuming system, we see that these attributes share a class. We can consider these <b>isolated</b> attributes. Perhaps some group of attributes are created in the ERP but can be edited or over-ridden in a downstream consuming system. These attributes also share a class. We can consider these to be <b>extended</b> attributes.<br />
<br />
While this small number of classes (primary, isolated, extension) already cover our current needs, should we have additional behavior combinations (say sourced in ERP, and only over-ridden but not edited) we can certainly introduce additional classes. In practice, usually only a very small number of behaviors is required.<br />
<br />
By disconnecting the discussion from specific attributes to the groups of attributes, it is possible to manage the risk that whichever way the schema evolves, the technology to support the different necessary behaviors will be supported. For example, knowing that we must support both isolated attributes and extended attributes ensures the schema will be able to express the difference and our replication and management processes must respect that behavior. Our solution will suffice, regardless of which (or how many) attributes ultimately end up classified in this way. More importantly, we can stop getting off-topic with discussion about specific attributes.<br />
<br />
</blockquote>What prompted the email was watching a vicious cycle repeat wherein the business asked for a capability that was complex, the technologists offered a simpler solution for specific cases, the business came up with yet another different complex example which prompted the technologist to revise the solution, etc. Both parties grew frustrated. The business didn't think they were being heard and worried about what they thought of as unknown gaps in the future solution. The technologist were struggling to create a high-level solution approach while constantly responding to low-level assumptions of how their solution should be implemented. Getting both sides to stop pushing an agenda is difficult but can be easier if you introduce terminology that is new to both parties. When they both have to take time to translate their opinions into a common vernacular it becomes clear which points are significant and who might just be causing trouble.<br />
<br />
The <b>primary-isolated-extended</b> pattern above is a very real pattern that I use in my every-day to help make sense of extremely complex enterprise-wide data flows. It really works. From the most advanced techie types, to the simplest business types, it is a tool that they can all understand. So now when they are bludgeoning each other in meetings, at least they are all using the same patterns to do it.<br />
<br />
<br />
<br />
<br />
<br />
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-36727852851000434132011-08-10T11:39:00.000-07:002011-08-10T11:41:26.669-07:00Talk More, Write Less
<img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 240px;height:237px;" src="http://neodiem.com/img/socialgraph.jpg" alt="" border="0" />
In some recent conversations, I've been helping a client to optimize their software development processes for a large, mult-site delivery. As we discussed how these resources who were used to working on small teams were going to be impacted by now working as a big team, a point of contention was the method for collaborating.<br>
<br>
When working with big teams, I try to structure the collaborations to be proactive rather than reactive. Namely, I set expectations that all team members should proactively seek out the information needed to do their jobs instead of establishing large-format, formal information publishing channels. Until now, I've never had the empirical evidence besides years of experience to substantiate this position.<br>
<br>
The gang at <a href="">MIT in Human Dynamics</a> was obviously struggling to promote this position and conducted a study to prove it. The <a href="
http://vismod.media.mit.edu/tech-reports/TR-622.pdf
">study</a> is actually really insightful in lots of aspects of workplace productivity, but especially in the need for high-touch collaborations.<br>
<br>
The study used cool devices they call <a href="http://hd.media.mit.edu/badges/ ">sociometric badges</a> that are equipped with infrared sensors, accelerometers, and microphones. These devices trace proximity, tone, gestures, and so forth. They paint a much more complete picture of face-to-face interactions.<br>
<br>
The results of the study supported a couple of conclusions that speak directly to how experience has shown we should organize our teams and the communication processes.<br>
<br>
For the study, they put these special sociometric badges on a team of 23 employees who work for an IT company in Chicago designing server systems. Over the course of a month they tracked everyone through about 900 jobs. The jobs ranged from little activities of 5 minutes to larger efforts requiring multiple days, all told they tracked about 1900 hours of work. They monitored time spent on the job, each activity, every interaction and a host of other variables. The interpreted result is that the most connected employee was <b>60% more productive</b> than the least connected employee.<br>
<blockquote>
[aside] The badges are powerhouses of information gathering and include accelerometers to gauge movement and speed, microphones which can discern tone and cadence, radios to capture proximity to other badges and location information, and much more. Can you say <b>Internet of Things</b>?<br>
<br>
Read more <a href="http://hd.media.mit.edu/badges/ ">here</a>.
</blockquote>
But just being connected is only the start. The point in time that disruptions happens is also important. If disruptions came while trying to accomplish a task, productivity dropped. Lack of disruption between tasks also resulted in decreased productivity.<br>
<br>
Boiled down it revealed that an increase in the standard deviation of network cohesion by 1 resulted in a ten percent increase in productivity. The more they collaborated, the more productive they were.<br>
<br>
This is not a license to gossip at work, but it is good evidence that going to lunch with colleagues, management by walking around, frequent breaks, socialization amongst peers, and self-service learning and systems are the keys to maximizing productivity.<br>
<br>
These highly productive behaviors are all <i>proactive</i> behaviors. They are successful because they set expectations for individuals that they need to participate in the group and seek out connections and information. These behaviors reward collaboration and penalize isolation. If your organization is constantly seeking for the right way to spoon-feed information to individuals instead of asserting individual responsibility for learning and connectedness, you aren't working in a high-performance organization.<br>
<br>
If you want to recognize the potential for productivity, looking for these behaviors (or their antithesis) is a good place to start.<br>
<br>
Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-87801320112682082292011-07-20T10:56:00.001-07:002011-07-20T10:56:26.884-07:00It's Been A WhileToday I saw a software architect at work. It doesn't happen very<br>frequently. Coming across someone that actually 'gets it right' and<br>demonstrates the true behaviors of a software architect is sort of<br>like winning a sweepstakes. Or more likely a local charity raffle. It<br>does happen, but it is pleasantly surprising nonetheless.<p>An architect has Vision.<br>An architect has Will.<br>An architect has Influence.<p>Like most good communication, it starts with a picture. For an<br>architect, this picture starts in the mind. It starts by listening,<br>and asking questions, and collecting the liquid perspectives of the<br>contributors and decision-makers and audiences and consumers.<p>Once there is a Vision, and sometimes before, a true architect relies<br>on their Will to align differing agendas, find common goals and<br>messages, and establish direction, approach and criteria for success.<br>In many situations Will must be exerted to extract necessary<br>information, expose individual perceptions, and uncover truth.<p>The exercise of Will to realize a Vision through the efforts of others<br>requires Influence. This is distinct from manipulation because it is<br>transparent and all parties are aware of the exchanges and the goals.<p>Until you acquire a Vision, your Will is pointless. Without Will, you<br>will have ineffective Influence. Without Influence you will have a<br>hard time achieving anything, and what you do achieve will be<br>inefficiently gained or comes only at personal cost (time, integrity,<br>relationships).<p>Today I actually saw an architect at work. It was a beautiful and<br>inspiring thing to witness.Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-39165728265077161032010-03-16T17:22:00.001-07:002010-03-16T17:55:40.715-07:00Finally Some Usable StorageI've tried a boatload of different synchronization tools and finally found one that actually works as advertised and meets my needs: <a href="http://www.getdropbox.com/">Dropbox</a>. Since I'm a very picky consumer (read: perfectionist), it is rare that I say a product is <b>very good</b>.<br>
<br>
<img src="https://www.dropbox.com/static/10231/images/logo.png"><br>
<br>
So what makes this product unique? It works simply, works quickly, and it is free for normal consumption. Considering that <i>my</i> definition of <b>normal</b> is anything but the norm, that's a big statement.<br>
<br>
Basically, you install the <a href="http://www.getdropbox.com/">Dropbox</a> client on your machine (Windows, Mac, Linux, what-have-you) and set the location for your Dropbox files. Anything that shows up there is automatically updated on the server. By using multiple clients with the same account you get real-time-enough (that's a technical term) synchronization across multiple machines.<br>
<br>
I use <a href="http://www.getdropbox.com/">Dropbox</a> for all my OneNote notebooks. And my work documents. And some source code. And some pictures. Pretty much anything I want to have A) backed-up automatically and B) available anywhere.<br>
<br>
Your free Dropbox account is limited to 2GB of data, and even for a storage hog like me this is plenty. And did I mention that the synchronization is fast? That's because it looks inside and synchronizes parts of files.<br>
<br>
I use a notebook, a netbook, a Mac, and a desktop PC throughout every day for work. As I was typing meeting notes into OneNote on the netbook I noticed it synchronizing in the background. Every few minutes the alert on my desktop popped up that updates were downloaded. Talk about peace of mind. When I'm done for the day, I walk out with my netbook knowing all my machines have the same information on them. I can edit any file on any of the machines and they all just stay in sync about as fast as I can switch from one to the other. When I type a new article on the plane, as soon as I get home, my laptop syncs. In the span it takes for my Mac to boot up, my files are already being downloaded. I can get right to work knowing I'm using the latest versions of the files, hassle-free and worry-free.<br>
<br>
For a while I was using the Gladinet software but it wasn't reliable, was too slow, and expensive. The GoodSync tools are really slow. In addition, it won't run on my desktop PC because I run Windows Server (boo!). With both of these, as with most of the sync solutions I've tried, the synchronization algorithm doesn't look inside the files so I was able to confuse the client with multiple updates and then lose some data. Inevitably this happened and pissed me off. And of course both of these cost money too.<br>
<br>
Among other things, I keep a Box.net account, a SkyDrive, a private FTP server, and heaps of both Amazon and Google Storage. Most of this is for work and collaboration, and I use them for encrypted back-ups too. But none of these make moving my data around easier than Dropbox. If Box.net (my previous favorite), or any of the big boys wants to know how to do synchronization right, check these guys out.<br>
<br>
And no, I'm not paid for this, I'm not affiliated in any way with Dropbox et al. I just rarely get the chance to toot the horn of something truly great and with such mass appeal.<br>
<br>Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-33571545159172374702010-03-02T09:31:00.000-08:002010-03-02T15:45:16.149-08:00The Gorilla in the Clown Suit<img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 240px;height:349px;" src="http://neodiem.com/img/gorilla.jpg" alt="" border="0" />
In my line of work, you deal with all sorts of different "leaders" and "managers". Typically, they've achieved their position through some confluence of skill, opportunity, and luck. They all have their positive and negative attributes, depending on the needs of the situation and your vantage point.<br>
<br>
The one I find most fascinating though is the Gorilla.<br>
<br>
The Gorilla type of leader is epitomized by being unruly and unpredictable, beating their chest when things are rough, blundering around leaving banana peels for others to trip up other people, and applying brute force to solve any problems they can't avoid by putting their hands over their eyes. Oh, they seem intelligent enough at first, but don't forget that their typical response to even minor irritations is to start flinging feces.<br>
<br>
When trying to identify a Gorilla, watch for them to put their hands over their eyes. You will notice this by listening to how they handle ambiguous requirements. You will often hear them using phrases like "I interpret this to mean. . ." and "I think what was intended. . .". They will insist on asking everyone to estimate their completion dates, but are totally uninterested in keeping track of the actual work required to hit those dates.<br>
<br>
Because they don't actually manage risks (or a traceable work plan) their project will inevitably have unexplained delays. They handle this through beating of the chest in more meetings about the dates and the issues. In these meetings they studiously avoid detailing the actual work involved or assigning any accountability. Unless of course, they think they can pin blame on some small monkey. At this point, they jump right on top of the unsuspecting ape and demand a full accounting.<br>
<br>
While this chest-beating occurs, they routinely change the process and expectations. This creates wonderful opportunities for others to fail in meeting these new expectations or realigning to the new process quickly enough. These little banana peels are perfect for tripping up the unsuspecting. These little slip-and-falls usually provide them with several potential candidates for assigning future blame.<br>
<br>
With all this mayhem occurring, the delays generally get worse, which means they now need to apply their brute gorilla strength in an effort to get things back on track. Since they haven't really been paying attention, and there are banana peels everywhere, this is harder than it sounds. So of course, now they get frustrated and voila! the feces flinging commences.<br>
<br>
If you find yourself working with (or heaven-help you FOR) a Gorilla, keep these simple rules in mind and perhaps you'll do okay.<br>
<br>
First, don't look them in the eye. Calling out that the endless meetings is a bad idea and unproductive is like poking the gorilla with a stick. It will only get you labeled as "uncooperative" or "not a team player". Instead bring your laptop and get your own work done if you have to be there in person. If possible, make it a conference call so you can put yourself on mute and get something done while the gorilla beats his chest.<br>
<br>
Secondly, watch the ground for banana peels. If the rules are constantly changing, give yourself plenty of time to do lots of non-value-add work aligning and re-aligning. This means get your monkeys up in the trees away from the gorilla so they can do the real work. Keep them isolated so that if (or more likely when) you stumble into one, you're the only one that gets hurt and your team stays productive.<br>
<br>
Lastly, find and maintain a poncho. Inevitably with a Gorilla there will be flung feces and finger-pointing. Make sure you've cataloged and highly publicized your risks and issues while maintaining transparency with your schedule, dependencies, and work plan. When things do turn nasty, keep your cool and trust in your poncho. If you've kept your poncho in good repair (being transparent and publicizing early and often) you should be prepared for the worst of it.<br>
<br>
In closing, it's worth pointing out that Gorillas aren't all bad. They are especially useful in death marches and suicide missions. When what is being undertaken is just completely unreasonable or the situation will likely require someone's career if it is to be successful, a Gorilla is a great candidate. When the situation is already beyond repair and you are just trying to salvage something, then chest-beating and brute force are great strategies for maximum gain. As a leader of multiple teams, unleashing a Gorilla to work for you is a quick way to identify which teams have their feces together and which people on which teams are worth saving. Good resources will escalate around a gorilla, and good peers will already have their ponchos firmly in place, rendering the gorilla ineffective.<br>
<br>Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-64054534454001396432010-02-04T15:23:00.000-08:002010-02-04T15:25:49.076-08:00Mostly Magic<img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 200px;height:213px;" src="http://neodiem.com/img/doingmagic4.jpg" alt="" border="0" />
Writing code can be highly scientific. Design software can be highly artistic. Defining architecture that encompasses elegant designs, is easy to test, efficient to construct, and still manages to satisfy constantly changing business goals is some science, some art, but mostly magic.<br>
<br>
Let's face it, every code monkey likes the way they write their code. Conversely, they think the code someone else writes is mostly garbage. In the same way, all designers thinks their particular designs are elegant and demonstrate "best practices" while simultaneously denouncing other designs as grotesque or impractical. These two elements that are combined when defining the architecture of a solution are both highly inflammatory and subjective. So how does one allow individuals to contribute according to their skills and from their own perspectives without turning the architecture into a Frankenstein-like monstrosity?<br>
<br>
The first technique is generally applied only at the design and code levels and is called <b>Separation of Concerns</b>. It is generally regarded to have originally been introduced by <a href="http://en.wikipedia.org/wiki/Edsger_W._Dijkstra">Dijkstra</a> in a paper written in the '70s.<br>
<br>
The general idea is that the various aspects of single effort should have their boundaries defined and respected in such a way that they can each receive focus individually. For example, separating how a screen displays information from the format in which the data is stored. Or agreeing on the bolt pattern for a tire so that tires can be manufactured by different suppliers and fit many cars. By creating a boundary between two areas of concern, they can each apply different ways to support the boundary independently.<br>
<br>
While this principle is often touted and used a tool to flog the unsuspecting for the need for services, loose coupled interfaces, interface contracts, etc. it can just as easily be misapplied. Consider how there are many components in an automobile that require access to the electrical system. In software we often see these as secondary types of functionality such as providing access control, auditing activities, or styling a screen. When you have these type of cross-cutting concerns, they tend to flout the rules by which we create primary concerns. Which leads to the aforementioned architectural monstrosity.<br>
<br>
In reality separation of concern is more than just for the elements, but it needs to be applied at all levels from how the work is structured, how the business processes interact, to how systems utilize shared resources. So working magic in your architecture will often involve applying this concept to more than just your designs, but will be present in your mindset and how you attack and decompose complex solutions into elements to be designed. Including the cross-cutting concerns as first-class concerns is definitely part of practicing this magic.<br>
<br>
The second technique doesn't really have a formal name that I've been able to uncover. It essentially is realizing that there is going to be a difference between what is asked for, and what is needed. Generally, speaking we all think that providing good software is about giving users what they want. In reality, it's about giving them what they need in an efficient way <i>and helping them feel like it's what they wanted</i>.<br>
<Br>
Ask any user what they want and they immediately turn into children. We all know that every kid wants a pony. Girls want it to be white and gentle. Boys want it to be dark with a white streak and wild side that makes it run really fast. And there are a few crazy kids who go all out and decide they want a unicorn. They are users, they have no idea what goes into the lifecycle of acquiring, maintaining, riding, and eventually putting a bullet in the head of said pony. They just want all these things they associate with having a pony!<br>
<br>
If you focus on giving them the pony, you are going to end up with really sad pony-owners. They'll have paid a premium for a beautiful pony that can't carry a rider and keeps growing until it's a huge horse that costs to much to keep. And who knows that they might have been totally happy with a cheap, durable, practical: <b>donkey</b>.<br>
<br>
The magic isn't just in realizing that a donkey can meet the need. It's on selling the donkey to someone who thinks they want a pony by focusing on what they get instead of what they think they want. Sounds hard, doesn't it?<br>
<br>
I told you it was mostly magic. And as an architect, it's what I practice every day.<br>
<br>Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-31854701.post-53978060588168774832010-01-14T13:34:00.000-08:002010-01-14T13:36:22.741-08:00Why Is The Build, The Build?<img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 211px;height:243px;" src="http://neodiem.com/img/buildingblocks1.jpg" alt="" border="0" />
Someone asked me recently about why I structure builds the way I do.<br>
<br>
For background, I should explain that I have a reference SQL build that I've been using for many years. It uses command files (.cmd) to iterate over a directory structure and create (or re-create) a database. It has no dependancies, works with integrated or sql server security, logs outputs, etc. Pretty much the usual.<br>
<br>
In this reference build, the structure is broken down so that tables are separate from keys and defaults and constraints and indexes, etc. Procedures are broken down by type, views are seperated similarly. The configuration scripts for users, data, etc. are all broken down as well. There are dynamic drop scripts that tear everything down before attempting to build everything back up.<br>
<br>
There were four specific concerns that came up about why it's structured the way it is that were raised. And it took some time go through the rationale. I figured I would capture the details of the thinking for you in this post.<br>
<br>
The first was about using granular scripts. After all, most tools, and many shops just merge artifacts into either a big script, or lumps of connected objects. For example, merging keys and constraints into tables. The second was about the use of the tear down scripts. If all the scripts are designed to create objects and not perform alters, why the need for tearing down en masse at the start? The third concern was about how we handle errors. Specifically, the build only outputs errors from every script, and doesn't actually stop the build. Lastly, the placement of indexes within the build, before the data load was questioned. Typical data loading would want indexes removed so that the load happens quickly and then indexes can be restored with the server online. These are all great questions.<br>
<br>
To address these concerns we need to set the expectations for the build process and how it fits into a larger team effort. The core expectation is that these scripts will be used by an automated process deploying a database repeatedly into multiple environments as well as by individual engineers who want to deploy locally or alternatively as needed. It is also expected that the scripts will be managed by a larger body of engineers as opposed to a single engineer or team who will manage all scripts.<br>
<br>
We can certainly discuss why having a single definition for the build or being able to leverage the larger team model for script development is advantageous or relevant at this level, but for this discussion these expectations are foundational.<br>
<br>
Given these expectations it becomes important to understand as early as possible, as many errors as possible that exist in every build. Essentially, since there are potentially many people making many changes, all present in a single build, we would want to uncover all the problems in a single pass because the different issues have a good chance of being unrelated. For example, changing an index or a table default won't affect whether a procedure will build so we want to catch all these errors in one pass.<br>
<br>
This also translates into loading the data before the indexes. If there is going to be a problem with the data because of an index, you would want to find it where the data is managed, not where the index is managed.<br>
<br>
Further, by using granular files, individuals change independent elements like keys, constraints, defaults, and so forth and the success or not of that change will be tied to a particular file which can be tied to a particular engineer and a particular change. In short, we want to know about all the errors as early as possible, but we also want to be able to pinpoint the source and responsible party for every error as efficiently as possible too.<br>
<br>
So a quick review:<br>
<ol>
<li><b>Use Granular Scripts</b> - so we can detect all errors independently and pinpoint the source and responsible party as quickly as possible.</li>
<li><b>Use Tear Down Helpers</b> - so engineers who are working locally or in alternative environments can restore to known point as quickly as possible with as little effort as possible.</li>
<li><b>Don't Stop On Errors</b> - so we can find all errors independently with a single run of the build.</li>
<li><b>Create Indexes Before Loading Data</b> - so we can find errors in the data load and pinpoint the source and responsible party as quickly as possible.</li>
</ol>
<br>
Hopefully it is clear how the specific patterns support the expectations.<br>
<br>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-40851660603896152452009-10-07T17:12:00.000-07:002009-10-07T17:34:18.920-07:00Azure AdventuresIf you are going to be using Azure, make sure your SQL Server instance isn't on a compressed drive. Also, running in Windows Advanced Server is much easier than trying to juggle all these pieces on Vista.
If, like me, you already have an instance of SQL Server you need to use the DSINIT tool to get storage initialized before trying to run anything. It's not a big deal just use dsinit /sqlinstance:. from the azure sdk bin directory. One trick is to use the period for an unnamed instance.
If, like me, you are running Advanced Server, you need to also run Visual Studio in elevated-mode if you plan to debug at all. And who's kidding, you have to debug right?
I've been playing with the SQL Azure CTP as well and I see some good things in store. I'll post some more useful learnings as I port more code into the cloud.Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-31854701.post-43619958997954020832009-07-07T13:50:00.000-07:002009-07-07T14:07:14.628-07:00Packaging Contracts for Services<img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 207px;height:172px;" src="http://neodiem.com/img/wcfservice.jpg" alt="" border="0" />
In working on a green field system recently (green field means it's new from scratch development) the discussion for a series of services turned to the subject of which type of data interaction should be used. Specifically, should the service be designed using message contracts or data contracts?<br>
<br>
Since it became clear that the basic inflection points were not well understood, I had to hold an impromptu clinic. After we finished, I wrote down the salient points and turned it into this post.<br>
<br>
The first thing to consider when choosing packaging formats is whether the messages need to be conformed. You see, many technologies don't comply with the published contract specifications choosing instead to rely on the lowest level XML serialization for interchange. If these messages already are in use, or you intend to interoperate with a system that has such restrictions, the choice is usually made for you.<br>
<br>
If you are playing green field (as in the conversation sparking this post) it helps to understand that data contracts have good portability which makes them widely applicable. Message contracts are less capable and therefore can have less portability .<br>
<br>
So the less conformant you are required to be, the more reason to choose data contracts. The more conformant your requirements, the more likely you will need message contracts or even base XML serialization.<br>
<br>Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-31854701.post-51922137933631905532009-06-02T17:07:00.000-07:002009-06-02T17:09:45.304-07:00What's The Hold-up?You know you are having one of those days when you're writing code like this:<br />
<br />
<blockquote> select top 5<br />
(select substring(text, (statement_start_offset / 2 ) + 1, ((case when statement_end_offset = -1 then len(convert(nvarchar(max),text)) * 2 else statement_end_offset end ) - statement_start_offset ) / 2 )<br />
from sys.dm_exec_sql_text(sql_handle) ) AS statement<br />
,last_worker_time<br />
,total_worker_time<br />
,last_elapsed_time<br />
,total_elapsed_time<br />
,execution_count<br />
from sys.dm_exec_query_stats<br />
order by last_elapsed_time desc<br />
<br />
</blockquote> <br />
This technique of pulling from query stats is great for finding those nasty performing culprits, especially in environments when you can't just attach a profiler.<br />
<br />
In case you were wondering, I use queries like this instead of sp_who or sp_who2 because it's specifically grabbing the statement that is executing not just the batch.<br />
<br />Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0