moebius recursive

In Japan they are testing personalized billboards similar to those seen in the movie Minority Report.

The new billboards, developed by Japanese electronic company NEC, scan the faces of passing shoppers, quickly determine their age and gender, and then display demographic-appropriate ads

Critics fear the technology as an invasion of privacy, but NEC say people will remain anonymous, their faces instantly deleted. The technology will get an American trial later this year.

Technorati Tags:
advertising, privacy, technology

technology

Interesting long-ish post on The Mobile Data Apocalypse, And What It Means To You. Of course, as noted in the posting, the assumptions are made based on the Cisco provided data — Cisco not exactly being a disinterested party when it comes to selling more WiFi and network gear.

The mobile industry is now completing a huge shift in its attitude toward mobile data. Until pretty recently, the prevailing attitude among mobile operators was that data was a disappointment. It had been hyped for a decade, and although there were some successes, it had never lived up to the huge growth expectations that were set at the start of the decade. Most operators viewed it as a nice incremental add-on rather than the driver of their businesses.

But in the last year or so, the attitude has shifted dramatically from “no one is using mobile data” to “oh my God, there’s so much demand for mobile data that it’ll destroy the network.” A lot of this attitude shift was caused by the iPhone, which has indeed overloaded some mobile networks. But there’s also a general uptick in data usage from various sources, and the rate of growth seems to be accelerating.

Technorati Tags:
data, ideas, mobile, network, wireless

technology

I find it fascinating (and a bit disappointing) that Gartner and others are just beginning to figure out that an effective Enterprise Architecture practice needs to start with an understanding of business strategy and direction and cannot (successfully) exist as a purely technical concern.

Perhaps this is because the early days of EA was really more of an application or technology architecture focus. The much lauded (and, in my opinion, over-rated) Zachman framework is really nothing more than a taxonomy as much as it wants to be sold as an ‘architecture’. If you can fill out the top row of Zachman, you have probably exhausted its usefulness (and really gained nothing more that the Who? What? so on perspective that you learned in elementary school).

Spewak then came along with another view of EA that was heavily technology oriented. The thrust of this seemed to assert that if you had a complete inventory of your applications and their interactions you were doing EA. No, actually you were on your way to doing portfolio rationalization – a valuable EA service, but not EA in its entirety.

Maybe it was the recent addition of Business dimension to TOGAF in release 9 that caused these ‘pundits’ to finally come to there senses and realize what successful EA practitioners were doing all along.

It would seem that this technology-focused approach has been the seed corn for the old saw ‘IT needs to align with the business’. I always thought it was odd that there was never an exhortation to have Accounting align with the business or Marketing align with the business. I believe that both parties are to blame here — the business needs to articulate a vision and plan that IT can understand and execute against. Without a clear plan from the business, IT more often than not will turn inward and focus on technology in a way that may or may not support business direction.

This disconnect on having business drive EA sort of reminds me of the strange looks that I would get about 10 years ago when I would try to explain that before an enterprise rush into slathering pointy brackets on their data and declaring that they are ‘service oriented’ that they should take the opportunity to make sure that there was a single enterprise definition of enterprise data and use services to expose them in a enterprise uniform way. ‘That has nothing to do with SOA!’ I was told. Tsk, tsk, that is data management, not SOA. Now, this ‘insight’ is all the rage, with every vendor and consulting firm thumping their chests and proclaiming that ‘data comes first’ and ‘the importance of MDM‘ as a pre-cursor to SOA.

Similarly the same pundits thundered on that it was laughable that BPM be tied to SOA. Problem is that BPM has a certain amount of ambiguity around what the M in BPM means for any given speaker. Is it Modeling? Management? Monitoring? Mapping? So, yes, for all of the non-implementation aspects of BPM, the service orientation part is largely irrelevant. But for any business process implementation that has system touch points (nearly all non-trivial processes do), services are (or should) play a role in exposing the business functions in a consistent, re-usable manner within the enterprise.

So, yes, Enterprise Architecture should be business driven, not technology driven. MDM is a critical underpinning for successful SOA. And BPM is probably the most visible part of service orientation and SOA is key to BPM implementation. What next, governance is key to enterprise SOA success?

Technorati Tags:
architecture, consulting, dubious, enterprisearchitecture, ideas, soa, technology

technology

As I was reading Martin Fowler’s post on ServiceCustodian I was struck by something that, in his words, didn’t smell right. After re-reading the article several times, I finally put my finger on it. He appears to assume that a service is no different than Java .class file or a .jar . Nothing could be further from the truth.

A true service should reflect a reusable business function, not merely some technical/programatic detail. As such, it should have a business owner who defines and controls what changes are appropriate to that function at a business level. Having coders making changes willy-nilly could prove disastrous to the business (but quite satisfying to the coders). It is unlikely that the business service owner will be able to understand the nature of a change from a patch (or even what a ‘patch’ was for that matter). There is no substitute for appropriate documentation and change control procedures to avoid errant changes.

This seems to be an increasingly frequent miss for coders: focusing on the code and what is convenient for the coder rather than on what makes sense for the business that they are supposed to be supporting.

Technorati Tags:
agile, architecture, badideas, design, development, dubious, ideas, software

technology

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.

Technorati Tags:
architecture, BPM, consulting, enterprisearchitecture, soa, technology

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.

Technorati Tags:
crap, dubious, mobile, n95, suckage, yahoo, yahoogo

technology

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.

Technorati Tags:
architecture, enterprisearchitecture, ideas

technology

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).

Technorati Tags:
dubious, ibm, technology

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.

Cheers, Mozilla.

Technorati Tags:
firefox, history, innovation, mozilla, netscape

technology

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.

Technorati Tags:
architecture, enterprisearchitecture, software, technology

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.

Technorati Tags:
digitalimaging, history, photography, technology

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’.

Technorati Tags:
architecture, development, dubious, opensource, chandler

technology

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.

Technorati Tags:
browser, firefox, history, innovation, internet, mozilla, netscape

technology

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.

Technorati Tags:
architecture, design, developerworks, dubious, ibm, software

technology

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.

Technorati Tags:
ibm, architecture, badideas, developerworks, esb

technology

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.

Technorati Tags:
history, microsoft, technology

technology

Daz3D is offering the previous version (5.5) of their Bryce 3D modeling software for free. The best thing is, if you try it out and like it, you can upgrade to the current 6.1 version for an unheard of $20USD through the end of June!

Technorati Tags:
bryce, 3d, software, apple, mac, free

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.

Technorati Tags:
spain, solarpower, alternateenergy

technology

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

technology

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

misc, technology