I was reflecting on the state of the BPM marketplace while returning from Software AG’s Innovation World. It seems that, by and large, there are few consultants out there who can advise you on the actual implementation of BPM (the hard part) but plenty of them that can fulminate on the easier theoretical portions. For example, here is a relative plot of the marketplace as I see it:
The justification phase is easy, as it primarily consists of the same pro forma advise for any IT-related project: have an executive sponsor, get business buy in, don’t try to justify a big bang approach, blah, blah blah. Check.
The analysis phase is where the Lean/Six Sigma types will descend upon you with endless discussion of SIPOC and other jargon. Don’t get me wrong, this is a valuable analysis to have, it just does not solve the entire problem.
Then comes the actual implementation and the sounds of crickets in the field. For implementation, that favorite consulting cliche comes out all too often: ‘it all depends’. Well, yes, it does all depend, but if anyone has successfully implemented BPM even a handful of times, they should be able to begin to synthesize a set of best practices and guidelines in general and offer specifics in a given tool stack. This area is sorely wanting — in most cases, even the vendors can’t tell you how to effectively use their own tool stacks in any detail.
Assuming that you have navigated the rocky shores of implementation, there are any number of Business Activity Monitoring and Business Intelligence vendors who will sell you their wares to help you visualize your process data as executive friendly dashboards and portals. They typically have nothing to say about effective data collection and meaningful representation of data.
architecture, BPM, consulting, enterprisearchitecture, soa, technology
I tried out the latest Yahoo Go mobile app on my Nokia N95 8GB. Go quickly demonstrated that Yahoo have no idea about the mobile market and their offering stinks. By focusing on bandwidth wasting adverts they undermine the entire mobile experience.
In my case I loaded up Go to try out the new voice search feature. Marginal success in that it mis-interpreted most everything that I spoke into it. Just for fun, I clicked over to check for my email. Up pops and error that it can’t connect to email. But apparently what it *could* do was connect to a server and start streaming some useless video for some Ford product that I had absolutely no interest in. If I wasn’t on an unlimited plan, I’d be really pissed. Oh, an there is no way to stop the ad until it downloads completely — sheer genius.
This is just further confirmation of what I have talked about before: Yahoo is clueless, it’s offerings suck and they should just agree to Microsloth’s offer to buy them and put them to sleep.
crap, dubious, mobile, n95, suckage, yahoo, yahoogo
I loved this blog post title Experience should guide, not constrain. Basically the point of the post was a recasting of the old cliche about ‘when all you have is a hammer everything starts to look like a nail’.
What the post really made be think about was the importance of having a breadth of experience in technology as well as depth in a few areas, especially if you are (or aspire to be) an enterprise architect. I personally have been lucky enough to work as a software developer, database administrator, network engineer, project manager and tech lead over my 20+ year career. I feel that each of these has helped me as an architect to bring all of that experience to bear on current issues and plans. Consider trade offs and side effects.
The converse of this is the puzzling phenomenon I have seen where people who only know Microsoft technologies declare themselves to be ‘enterprise architects’ when in fact they are little more than one-note technologist. This is particularly laughable in enterprises that aren’t 100% MS technology. These EAs probably only have about 5% of the picture — have they lost track of what the ‘enterprise’ really is. So it is no wonder that the way they ‘fix’ a problem is by insisting that it move onto the MS platform (which is my experience is usually the wrong answer).
So in technology as in life, grow what you know, keep learning and try new things.
architecture, enterprisearchitecture, ideas
I had to chuckle at this article wherein IBM seems vexed that the number of computer science and IT graduates is declining in the USA. Really. IBM is probably one of the IT companies that led the charge to offshore jobs and slash US IT positions.
And they wonder why IT is not as attractive an option for college students? They have already sent the message that ‘cheap’ is what they want; not homegrown (or even good, for that matter).
dubious, ibm, technology
Depending on how you do the math, either yesterday or March 31st is the 10th Anniversary of Mozilla. In a way, it doesn’t seem that long ago. And in thinking about it, it hasn’t been ten years, because the real game changer didn’t get started until six years later (in 2004) when the first release of Firefox arrived on the scene.
Since then, Firefox has delivered a little over three years of innovation and improvements. More than can be said for the stale, outdated default provided by a large, malicious corporation. It will be interesting to see what Firefox is delivering as it reaches it’s tenth. The inclusion in the next release of semantic web awareness is (to me anyway) a sign of good things to come.
firefox, history, innovation, mozilla, netscape
Reading through this post on The Key Difference Between Developer and Architect Roles I was reminded of a few other key attributes that successful architects possess that developers and (certainly not ex-consulting firm wanks) tend to not have.
Once upon a time I was an architect working on an large packaged application installation along with two ex-consulting types. These guys had zero technical background and were basically good for creating and following task lists with no understanding of what the tasks were (or could be). Any conversation with them ended with them drolly replying ‘well that’s nice but it’s not in scope’. Problem is that if they had a modicum of technical/architectural skill, they would have recognized that every suggestion was in scope and had the recommendations been acted on would have saved the project enormous amounts of time and money.
For example, their task list said that they should rubber stamp the scripts they had for data transformation and movement. Well, in the ten years since the original scripts had been written, the company had acquired an ETL tool that would have made creating, modifying and maintaining the data movement portions much easier and quicker. But, no, that was ‘out of scope’. The ‘task list architects’ spent something like 700x the estimate for the ETL effort to essentially build a hairball-esque shell script-based hack that failed miserably. The team spent huge amounts of time and effort trying to maintain the scripts. On top of that, they had huge data consistency issues because the scripts barely worked in one scenario let alone have the flexibility to accommodate new requirements.
That was just one of their many ‘successes’ on the project. They basically did the same with the reporting for the system. Rather than use the ‘out of scope’ modern BI tools, they ‘re-used’ the 10 year old scripting hacks. Another huge dose of fail. And again with environment (mis)management. Somehow through their utter ineptness they ‘required’ something like 39 copies of the production environment to complete their testing. Thirty nine. The mind boggles.
But this is what you get when people who can barely write a requirements document (but have ‘experience’ from big consulting) adopt the title of ‘architect’. Real architecture requires enough vision and understanding to know when to make both strategic and tactical decisions that enable a project to deliver a quality result. Real architects understand what changes can be made and why, without greatly (if at all) effecting scope. Task list ‘architects’ can’t see beyond their own tick lists.
architecture, enterprisearchitecture, software, technology
Wired has a brief article that shows just how far high speed photography has come in the last 120 or so years. We’ve gone from the (then miraculous) 6 millisecond (10^-3) shutter speed of the galloping horse in 1887 to the current 110 attoseconds (10^-18) image of electron drift. Amazing stuff.
The photo that they have of a nuclear blast reminds me of an electron microscope image of some nasty virus/mutagen. It really is a fractal world.
digitalimaging, history, photography, technology
I found the comments following the article on boingboing about the Chandler calendar project a lot more insightful and informative that the semi-gushing review itself.
I guess mozilla was an exception, but what I call large ‘corporate OSS’ projects don’t always work out. I also suspect that it is not a characteristic of OSS per se. It seems one of the issues was there was no pressure to deliver anything. So rather than focus on product delivery they created their own OS and programming tools as well as what is reported to be a unwieldy and poorly thought out architecture. Don’t know that anyone is in the market for those things.
This reminds me of the first internet bubble when people would rush out and get office space and funding and have no idea what their product or business model was (or should be). They just wanted to be ‘doing the startup thing’ not actually delivering anything. Then it was time for what I referred to as ‘the rise of B2B and B2C’ as in ‘Back To Banking’ and ‘Back To College’.
architecture, development, dubious, opensource, chandler
It has been a bit amazing the amount of rending of garments and gnashing of teeth that has gone on around AOL announcing that it is ending support for Netscape Navigator in February. Navigator and Communicator have been dead to me for years. I jumped to the lighter weight and more feature rich Mozilla builds when they first became stable and then made the leap to the even more nimble Firefox when it emerged.
I think back to the early-90s when I was using the nearly unheard of Mosaic browser to access the precious few sites that existed at the time (and creating a corporate site using the not-so-stable NCSA server code). Then there were rumblings on the Usenet forums about this upstart beta of the ‘mozilla’ browser. Fledgling webmasters were horrified by this new browser because you could set the number of download treads that the browser could use to access your site. Horrors! This would certainly be the end of the Internet — it can’t possibly scale! But somehow we survived and the Mozilla Communications Corporation became Netscape and the rest is history.
browser, firefox, history, innovation, internet, mozilla, netscape
Wikipedia defines a shanty town as:
… “marginal” or informal settlements are units of irregular, low-cost dwellings, usually on lands belonging to third parties, and most often located on the periphery of cities. These dwellings are often assembled from pieces of plywood, corrugated metal, sheets of plastic, and any other material that will provide cover.
This is what immediately sprang to mind as I read yet another article on IBM developerWorks that left me shaking my head. This one was on ‘situational applications‘ which to me sounds like a euphemism for ‘zero design hacked together crap that the enterprise has to deal with for the long term’. I’ve seen far too many of these things actually in production to have much positive regard for them. For those who favor the ‘city planning’ paradigm for Enterprise Architecture, situational apps are the shanty towns of the enterprise.
Someone needs to clue IBM in on this basic fact: any real or imagined efficiency in development approaches zero benefit in the overall lifecycle of an application. This effect is negatively magnified when developers ‘just have to’ use some new technology-of-the-week for their project (the veritable random pieces of plywood and corrugated metal of the software shanty town). Then, after the shininess has worn off, the application represents a one-off island of technology that the enterprise has to deal with. And deal with. And deal with. It is absolutely amazing that in the ‘Challenges of SAs’ portion of the article that cost is never identified – increased cost to support, maintain and (hopefully) decommission the errant development.
Overall, the SA approach sounds like a noble effort for a lab setting to see what benefits can be gleaned from the endeavor. Unfortunately, in many cases, the ‘lab’ will be the enterprise production environment. I have a feeling that SA will improve IT about as much as shanty construction enhances modern building techniques.
And please remember, the fastest path to the wrong answer is still the wrong answer.
architecture, design, developerworks, dubious, ibm, software
Ok, maybe the title is a bit strong, but it is the one thing that struck with me when I was reading through a posting on ESB-Oriented Architecture at IBM DeveloperWorks. This is the part that struck me:
Rather than the IT field of dream’s slogan of “if you build it, they will come,” a more appropriate slogan comes from Extreme Programming (XP): “You aren’t gonna need it.” This slogan is shorthand for a very practical principle:
Always implement things when you actually need them, never when you just foresee that you need them.
This principle—don’t build it until you need it—is the opposite of the IT field of dreams. Rather than building it because you hope that someone will want it, do not build it until you know someone wants it. Then you can make sure to build what they want, not what you think they might eventually want. And you will not incur the costs of building it until you are also ready to reap the benefits of having built it. This principle is just a good business philosophy, and it applies to the IT department as much as any other parts of the business.
This may have some applicability at a ‘micro’ level, say, when you are deciding whether or not to write a function or class — a task that may take minutes or hours. But, I think it absolutely misses the mark for larger scale efforts that might take months or years. I believe this posturing also reflects the disdain that the ‘agile‘ and XP herds have for sound architectural principles. Coding is not architecture. Nor is it proper documentation.
A successful enterprise architecture strategy should reflect a robust enough understanding of the business that it supports to be able to anticipate when changes are needed and build them before the business actually needs them. This is how architecture adds value to the enterprise, not just to a project. However, if you enter into a reactive process where you are trying to build out significant infrastructure at the same time that a project or projects is intending to consume it you will likely fail.
To put it in the terms of the posting: the business would have come (and gone) because you couldn’t build it fast enough to add value. And rare is the project that will just hang around for a year while you quickly try to deliver. Something.
ibm, architecture, badideas, developerworks, esb
This article sheds a bit of light on the true nature of Microsoft
revisionist history innovation. The final bit sums it up nicely:
The PC world might have looked very different today had Kildall’s Digital Research prevailed as the operating system of choice for personal computers. DRI offered manufacturers the same low-cost licensing model which Bill Gates is today credited with inventing by sloppy journalists – only with far superior technology. DRI’s roadmap showed a smooth migration to reliable multi-tasking, and in GEM, a portable graphical environment which would undoubtedly have brought the GUI to the low-cost PC desktop years before Microsoft’s Windows finally emerged as a standard.
But then Kildall was motivated by technical excellence, not by the need to dominate his fellow man.
history, microsoft, technology
Spain’s Solar Power generation tower is an amazing piece of engineering that can generate 11 Megawatts of power without emitting any greenhouse gas. Apparently it is quite a thing to see as well.
spain, solarpower, alternateenergy
Microsoft’s Yellow Road To Cairo is a must read.
This is a topic that I have talked about for the last ten years, but no one seemed to want to hear it. Most would just breathlessly pant on about how MS was such a great marketing and technology innovator. Ha! What they did establish is a near licensing stranglehold via their bogus announcements meant to shunt the market. Announcements that they likely never intended to deliver on (and, in fact, never did).
Fraud as a Business Plan
The magic of the Internet is helping to point out the tragic fallacy of believing in Microsoft’s promises. Microsoft assures us that it won’t ever slip half a decade between operating systems again, but what about the fact that that’s all it has ever done?
Looking back, while it appears Microsoft has shipped regular products, in reality what it has shipped in the last two decades of Windows has been a series of apologetic stopgaps without ever being ready and able to ship what it actually promised to deliver.
Those placeholder products were far inferior to what competitors were offering. They were actually far inferior in many cases to products that predated them by many years.
In addition, the futuristic Cairo plans Microsoft failed to ship were actually delivered years ahead of schedule by other vendors. Why does Microsoft keep getting airtime? The company is a huge fraud, and has been for decades.
technorati tags: microsoft, history, marketing, fraud, ideas
It seems the UK version of the high tech passport has failed the first hurtle — a writer at the Guardian and a tech expert managed to crack the passport security with relative ease. Seem those who hatched the security scheme made the rather naive mistake of going to great lengths to secure the communications between the RFID reader and the passport, but used information that is available on the printed passport as the ‘key’ to unlocking that communication. Just dumb.
Fatally, however, the ICAO suggested that the key needed to access the data on the chips should be comprised of, in the following order, the passport number, the holder’s date of birth and the passport expiry date, all of which are contained on the printed page of the passport on a “machine readable zone.” When an immigration official swipes the passport through a reader, this feeds in the key, which allows a microchip reader to communicate with the RFID chip. The data this contains, including the holder’s picture, is then displayed on the official’s screen. The assumption at this stage is that this document is as authentic as it is super-secure. And, as we shall see later, this could be highly significant.
technorati tags: passport, security, encryption, rfid
I would be completely remiss if I didn’t at least mention that today is World Usability Day 2006. Unfortunately, I won’t be able to make it to the local event, hosted by LexisNexus in Dayton.
I have been a champion of software usability in my own small way over the years and take great pride in having introduced HCI concepts and usability testing to previous and current development projects.
technorati tags: usability, worldusabilityday
Check out this video from TED where Jeff Han demonstrates an intuitive interface-free touch screen device and several applications that make use of it. The photography lightbox and the NASA mapping application are absolutely stunning. Now this is some real innovation in computing.
technorati tags: ted, interface, ui, ideas, innovation
Nokia is shifting its focus from just making mobile phones to offering more software and services to customers.
One front they are moving on is the widget arena, with their new WidSets site. This site allows you to configure widgets on the site and then send them to your mobile. More on widsets as I get a chance to play with them.
Update: Unfortunately, I won’t be able to find out anything more about widsets. Running the client on my Nokia 6620 causes it to lock up solid — I have to pull the battery out to regain control of the device. Apparently older phones may have problems with the Java client that widsets makes use of. Ah, yet another excuse to upgrade phones…
technorati tags: nokia, widgets, services, software, tools
Im a bit surprised that I haven’t heard more about this (perhaps the hysteria will whip up as we get closer to the date). The gist of it is that with the newly enacted Daylight Savings Time (DST) guidelines older Java Virtual Machines (JVMs) will not adjust for DST properly starting in 2007. The first event will happen on March 11, 2007.
If you have been looking for a reason to upgrade to JVM 1.5, this should do.
technorati tags: java, dst, jvm