Posted by TomRose on August 31, 2006 under EA, Innovation | 
Excellent article about the culture at Google by Thomas Claburn at InformationWeek, Google Revealed: The IT Strategy That Makes It Work . So if Google has the formula we all just imitate it, right? Unfortunately, it would just be an imitation, and not the real thing. What we can take away from Google is that their culture of innovation is tailored to attract and most importantly retain a target talent pool that will move the company in the direction of their corporate vision. Every company has a different tempo and vision, so finding the right culture to motivate innovation within those parameters can be difficult. When we are talking about a corporate vision requiring innovation to grow revenue, it requires a much different culture than the vision for an industry that is going through a consolidation phase. As corporations move focus from keeping the lights on to fostering innovation to grow revenues it requires a culture change. Given that fostering innovation may require a different culture, a part of the company may be different from the rest. Guy Kawasaki has some great advice in this area, “Don’t be afraid to polarize people.” Although he is talking about customers, I think the same can be said for internal talent. Having multiple sub-cultures, or changing it everywhere is going to alienate a percentage of the company. However, the alternative is the company stagnates because it can’t migrate to a culture fostering the innovation required for a new vision.
Joel Spolsky talks about some management styles, and The Identity Management Method seems to gel with what Google and Guy are talking about. Another note from James McGovern articulates the attribute of transparency, and I believe this management style depends on transparency. A culture centered on innovation seems best served by this management style.
It’s safe to say that the most successful companies will cycle through different cultures as they grow, and their industry matures. Those companies that cannot make the multiple transitions will disappear.
Posted by TomRose on August 25, 2006 under SOA |
I just read an article about business process reuse “Don’t Bank on Reusing Services.” and found it to have an interesting perspective. However, I draw somewhat different conclusions than noted in the last paragraph of the article about the benefit SOA brings to BPM being overstated.
Taking a lesson from the past, when creating system level services for consumption by other development teams, maintainability and usability were top factors in creating the service interfaces. These two factors usually opposed each other, and a balance of both had to be maintained. The approach defined a set of lower-level service interfaces that could be combined to create high level façade interfaces for various consumers. The low-level interfaces would seldom change, and the number of different façade interfaces would increase rapidly during early adoption, plateau, then steadily decrease as consumers of the service adopted common usage patterns. So reuse is high at the low-level service interface from creation point on, and the high-level façade interfaces took some time before reuse was also acceptable at that level. This happened as consumers were still working out just what they were doing the same, and what was different. It took time for them to communicate with each other, and usually that communication was facilitated by the service producer. Until ultimately, those high-level interfaces were consolidated into a cohesive set of reusable services.
For our current day definition of SOA the approach is very similar. The low-level business service interfaces are mostly defined by the service producer. The high-level business processes mostly defined by the service consumer by orchestrating the business services. In the article noted above, the business processes created with BPM (task, activities, etc), are hardly ever reused. How could that be? That would indicate that from a business operations perspective there were no replicated business processes. If this is actually the operations model, then that is what is to be expected. Unfortunately, in many cases that is the case, and unless there is a concerted effort to change that model, our implementations of SOA will all look just at described in the article.
So what has to be done different to get a better result? In creating technology services usually the producer engineers and consumer engineers creating the business applications (business processes) would hash it out in a war room for a few hours. When they emerged, all would be well. Today the players are the software engineers, business analyst, and business process owners, both on the producer and consumer side. As we bring the business process owners into the mix they tend to have very different views of the same solution space, and sometimes very different personality types than the technologists. So the concept of creating applications of yesteryear, and creating reusable business processes by orchestrating numerous business services of today, is the same. However, the players have changed and so we need new approaches for the solution space. This means solution architects today have to understand the technology, business operations, and also how to build relationships to foster effective communications with all the roles at the table to be successful. As noted in the article, process owners have to be involved.
The author, Bruce Silver, also indicated that the reuse SOA brings at the business process level may be overstated. I agree from one vantage point, but realize at the business process level, it’s all about business operations, and SOA is not a definition of our business it’s a way to model it with the technology in place. If that model shows little business process reuse, perhaps the operation model is the source of minimal reuse, not the approach we use model it with technology.
As part of enterprise architecture the business operations model must be clearly understood to create the business architecture that includes the business process definitions. If the operations model shows there should be process replication and the business processes are all defined differently, the misalignment is happening way before SOA is ever in the picture. However, this may never be seen until an SOA implementation was ever tried. Once again we can see iteration is the key to successful creation of anything.
Tom
Posted by TomRose on August 23, 2006 under RFID, Sensor |
I was looking at the Open Geospatial Consortium (OGC) Sensor Web services over a year ago, and although they had some emerging ideas, it did not seem cohesive at the time. However, a colleague in Australia’s national science agency noted he was looking over the OGC specifications, so I took another look. I was pleasantly surprised to see they have made significant progress and have released specifications for public review regarding a global sensor network.
Here is a video of the demo for the phase 3 work that completed last year.
EPCglobal has been the global standards organization for RFID hardware, RF, and software interoperability protocols. Although they have great success in hardware and RF, the software interoperability standards have been slow to emerge for public review. The reason I mention this about RFID is I believe that RFID readers are just another type of sensor. Also RFID application authors are slowly realizing that geospatial information will be required to better utilize RFID event information. I suspect the OGC sensor standards will have much greater adoption than a niche technology like RFID, and so hopefully the two industries will collide.
The OGC Sensor Web working group website contains the latest drafts of the specifications.
When we talk about Web 2.0, I envision more services like sensor nets and the applications that utilize them. When we start to put interoperability standards in place like Sensor Web from OGC, combine it with emerging networking technology like Zigbee, WiMax, and Dedicated Short Range Communications (DSRC), then things start to get exciting.
Cheers,
Tom