Posted by TomRose on August 5, 2009 under EA, SOA, Virtualization, XML | 
As a follow-up to “XML Appliances – Strategic Shift or Tactical Technology Flash”, I’m leaning toward a flash. Having purpose built hardware appliances for very specific needs can make sense, but as general middleware integration devices, I’m not buying into it.
For instance, physically hardened appliances as application level perimeter security devices seems to make great sense, as they have a very specific purpose in terms of application level logic they perform (security), plus their physical security attributes. Quickly, vendors move beyond specific purpose and start to position these devices as general purpose devices for enterprise integration, by definition, it’s no longer specific purpose, and the benefit/cost curve starts heading in the direction of zero fast.
As an industry we have moved away from purpose built hardware in the enterprise for decades, as the support cost is high for this model. As we move to virtualized environments and cloud computing, we are actually accelerating our move away from purposeful built hardware devices. So if these devices start popping up in the general purpose integration space in support of SOA, think long and hard about where your organization is headed in terms of infrastructure virtualization, and where these devices would fit in that strategy.
Posted by TomRose on December 29, 2008 under EA, SOA |
XML Appliances for increased performance of XML based messaging protocols are the rage it seems. Forum Systems, Sarvega , Reactivity, Layer 7, DataPower are a portion of the players that have emerged over the last few years, and are being acquired as fast as they are created.
- Sarvega, acquired by Intel
- Reactivity acquired by Cisco
- DataPower acquired by IBM
Better XML processing achieved through XML/XSLT engines implemented in hardware, as opposed to software on a general purpose CPU. A bit oversimplified, however, it’s the general direction. Interestingly, the industry has spent 20 years ridding itself of special purpose hardware for everything, driving toward software solutions. Although, with the advances in programmable hardware it’s possible special purpose hardware is in the realm of possibilities for the large enterprise.
The products/appliances emerging are jumping on the SOA rocket sled, showing how the products could be utilized as an enterprise service bus as well as perimeter security devices. What is not emerging is a well thought out story of how an enterprise, with its vast inventory of overlapping software solutions can best take advantage of the special purpose hardware, how to manage it effectively; and then most importantly, is this technology really a strategic shift, or tactical technology flash?
I plan on diving into the subject to really understand where it plays. There is a steady stream of patents in the pipeline, but so far I find them empty of real innovation. Where is the rest of the industry headed? Is anybody out there having significant success with these products or others? As always your thoughts and comments are welcome.
Best Regards,
Tom
Posted by TomRose on November 10, 2006 under EA, SOA |
There are a few posts about the Enterprise Architecture Conference (EAC), and the lack of discussion about SOA. I did not attend so I’m only getting the information second hand, and most of what I read seems consistent. Either the session was about SOA or EA, and the two were never really blended or a relationship clearly articulated. I have some thoughts on why that occurred.
Enterprise Architecture, well everyone has their own definition and no need to go there for the moment. Perhaps we can agree that SOA is part of a corporate EA practice. I think it’s also safe to say that Integration and Business Architecture are part of EA as well. SOA is an architectural approach that blends Business & Integration Architecture providing an agile integration and pallet of business services to enable business operations.
EA also contains application, infrastructure, and information architecture. Regardless of the definition and what name the architecture type is given, how many you have, etc, these are all in a category of Technical Architecture. Many times I think we stop here and just equate the two (EA = TA), instead of understanding TA is just a subset of an EA practice. From my experience it’s the easiest component of EA, and if all I had to do is define and create the enterprise technology portfolio to run the business, life would be grand!
Unfortunately, a successful EA practice also consists of strategy/planning, governance, portfolio management, program management, and education. Then strong ties with business strategy, strategic sourcing/vendor management/procurement, and an EA process to tie it all together.
This is where EA gets hard, focus on the non-technical critical success factors and nothing ever gets pushed out into the daily operations (ivory tower syndrome). Focus on the TA, and the effort is siloed where it began and never gets full enterprise reach. Only because of tactical cost reduction and functional needs of the enterprise such as, new ERP functionality, system/datacenter consolidation, identity management, federal and state regulation/legislation, web portal, etc, do enterprise initiatives get completed. Both have to be done, and the companies that can, will be the ones that move from good to great.
When looking at the scope of an EA practice, SOA is a very critical and small piece of the complete picture. The same can be said for the EA frameworks and models.
Cheers!
Tom
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 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 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!“