Posted by TomRose on October 17, 2006 under SOA | 
Todd Biske has a post “Success with SOA“ that I found very interesting, and subsequently commented on. The subject is simply about successful SOA by focusing on delivering business value instead of SOA implementation.
My take is that some organizations are so far away from all the knowledge, infrastructure, and governance that has to be in place to support an SOA approach, a mega-project is created, with the focus on SOA implementation instead of business value.
Grady Booch’s blog entry, Thursday, October 12, 2006 Snake Oil-oriented Architecture, expresses a similar point as well.
Tom
Posted by TomRose on September 27, 2006 under NFC, Open Source, RFID |
It has not received the attention of open source software; however, the same concept is being applied to hardware components by releasing the design and usually a working simulation model via hardware description language such as VHDL (HDL Tutorial, FreeHDL ). OPENCORES is one of the consortiums focused on Open Licensed Hardware, and was founded sometime in 2000. The fact that hardware is being open licensed gives much credit to the model of open and free components, as the real value is how to put those components (hardware and software) together into a solution.
I’m not an advocate that absolutely everything has to be open licensed, and not to say that the industry as a whole has the best open licenses today, or have figured out the best business model for both the producers and consumers. Although, I am convinced that open licensed technology is invaluable for increasing innovation, accelerating adoption and evolution of commercial solutions/services, as well as distributing the risk of technology development across a wider participant base.
Now, what prompted this post was a mail list message about OpenPCD, a RFID reader, both hardware and software with an open license. This type of technology is part of a broader movement referred to as NearField Communications (NFC).
Also related, the recently finalized JSR 257 (Contactless Communication API ), that supports many connection interfaces, such as ISO 14443. You will see this particular protocol (and others) referred to in the NFC forum noted above, and also implemented in the OpenPCD project via and open source component called librfid . So there is much movement in this space across the world, in addition to security and privacy controversy with its use. You can look toward implementation of this technology in passports to find heated debate about the additional security it brings, and its appropriateness in this solution space. Search Bruce Schneier’s weblog for “passports” to get a security perspective of the technology.
There is no doubt an open license approach to technology will continue to be adopted. We just need to prove out the business models that will continue to fuel the development of open licensed technology. As nothing is free, somebody always has to pay.
Tom
Posted by TomRose on September 14, 2006 under EA |
Customers Get Hip to System z Value Proposition
For the past five years I have been interested in doing a value study for consolidating distributed mid-range servers back to mainframe technology; however, I was always laughed out of the room. The server virtualization and provisioning along with the high utilization capabilities are very attractive. With some of the moves as noted in the article above, I expect there is some significant value here.
Grid computing allows the utilization of all computing resources, and absolutely is part of the picture. However, in large organizations where data center, server, and storage consolidation are paramount to driving cost reductions, mainframes seam to make sense. Moving back to the mainframe for mission critical services (and what isn’t today), seems to be something worth evaluating for your organization.
Tom
Posted by TomRose on September 7, 2006 under RFID |
Another version release, we are now at RFID 2.0 in Japan. My first thought was why do we keep doing this, and for a moment I was bitter. After some reflection, I came to the conclusion that I agree with motivations to put the version releases on everything; SOA, RFID, Web, Business, but not the actual versioning itself. I’m sure the marketing teams are trying to get some excitement in the industry, as that leads to focus, innovation, and of course customers. Although the motivations may be admirable the method seems entirely ineffective. I wonder what the empirical data shows relative to adoption rate of technology as it’s arbitrarily assigned a version.
Tom
Posted by TomRose on September 4, 2006 under EA |
Very well articulated advice from a seasoned leader of enterprise architecture. The blog title Management Rants is a little misleading, as there are no rants. It’s a collection of vivid depictions about enterprise architecture challenges, and how to work through them while keeping your integrity intact. After reading all the posts, my first thought was that I need to read these again, as there is excellent advice and information in every post.
Tom
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
Posted by TomRose on June 11, 2006 under SOA |
Don’t have SOA 2.0 yet, that’s great! Don’t go there as it’s little more than marketing material than any evolution to service oriented architecture. Service Oriented Architecture (SOA) is really not a new concept. If you look back to what was called Enterprise Application Integration (EAI) or how software engineers built software since as long as I can remember, what we strived to build were services at many levels. So what has changed? Standards for integration, messaging, and orchestration are driving most of real value around creating and consuming services. For example integration is being achieved by Web Services providing technology independent mechanisms to publish business and technology services. This has helped create a common language to communicate about designing, implementing, publishing, and consuming services, as well as the benefit to creating services to drive business value. Where is the business value? Seamless communication across the business for customers, business partners, and staff, as well as maximizing the ability for change throughout the enterprise, is where the value of SOA exists.
Because of the standards, and now the firm SOA message that is being communicated, vendors wanted to create SOA products. We have the birth of an Enterprise Service Bus (ESB) as a product, and for the most part ESB is a stack of technologies that support an SOA approach, great in and of itself, although ESB is not the complete picture for SOA implementation. What services get exposed, granularity of their interface, service semantics, service orchestration, etc. all makes up SOA. SOA 2.0 is now the addition of event-driven architecture (EDA) to what we now understand to be SOA. Event-driven architecture is best enabled by a SOA approach, and that’s great. However, every time we find a good use for SOA and create a product around it, throwing another version to the acronym does little more than add confusion to what businesses should be focused on when understanding what makes up SOA, and why it’s good for their business.
I understand the concept of SOA 2.0, as software vendors must strive to differentiate their products to stay alive to give us these great products in the first place. However, lets utilize the momentum SOA has in the industry to continue to define standards, create products, and educate our business leaders to the value of an integrated adaptive enterprise. Let’s not derail it with trying to hype it to 2.0 before we have launched SOA into a stable orbit around our little blue world.
As so elegantly said, “please sign the petition and stop the madness!“
Posted by TomRose on May 17, 2006 under RFID |
I have been listening to the presentations, and I’m very pleased to hear meaningful discussions about the security and privacy issues. The constant barrage of mindless banter with the “technology evil” slant in the media and books was wearing extremely thin.
Also, the privacy issues being discussed in detail are related to RFID/sensor technology, but really uncover the overall issues to the current collection and management of private information (credit card companies, loyalty programs, etc), regardless of the technology used to capture and associate the information.
Although this is for the EU, speakers from other countries outside the EU, including the US, are participating.
http://www.rfidconsultation.eu/
Streaming video:
http://scic.cec.eu.int/streaming/char/