Phil Windley in InfoWorld: LiveServer creates real-time Web:
LiveServer is middleware that supports real-time interapplication messaging via HTTP, using a publish-and-subscribe model. Applications, including Web browsers and spreadsheets, can use KnowNow-supplied components called connectors to publish to the server or subscribe to its message queues.
Sitting in and blogging a webinar:The Race for Business Service Management: Rev Up Your Mainframe
Business Service Management (BSR) is one of those many names tossed about but little understood...by me at least. So I'm going to sit in on this webinar and blog some of the more interesting bits...
Just logged on to the seminar and this one has a nice interface with the media player in a small box on the upper left and a big space on the right for the meeting deck (the currently hip term for the slides in a powerpoint presentation). We'll see how they use it.
The mainframe in the data center has reached a level of maturity of Operability, Reliability, and Cost Efficiency that distributed systems have not yet reached. Distributed is reaching that, but still not there to offer businesses those key factors. These two components of the data center are at different stages.
Data collection of components deployed on mainframes (and distributed architectures) needs to be focused on that data that can be used to monitor and adjust / re-allocate service resources.
Service management needs to tightly link business processes to the IT assets in order to be successful. It also requires lots of event data and configurable / automated systems.
BSM means monitoring all of the different components for those parameters that may indicate and drive change in configuration.
The business impact of the components running on the mainframe must be known and part of the equation that includes the monitoring data collected. Combined, then impact of changes to the service level of a component can be expressed in business impact terms (i.e., Business Analysts won't have data needed for this day if this job doesn't get done by HH:MM pm).
BMC Software has a BSM solution and a service organization to support.
Siebel Systems - Events - Siebel CIO Shares Best Practices for Release Management
I'm hoping to learn more about Release Management, since it's a discipline I haven't really had an opportunity to work in or explore, despite many years in IT. It seems to he really necessary to control change management in both business process and IT infrastructure.
Recap: The presenter didn't really give many details on the nuts and bolts (coordinating development cycles with release cycles) of how RM happens at Siebel. What was impressive though was his imersion (sp?) in what the key KPIs of Siebel are...which really does show alignment of IT with business.
Continue reading for what I blogged...
RM and reduced IT complexity can improve agility in that you only have implementations to change when you want to change.
Best RM Practices...
RM KPIs...
Real Big (Elephants) and Real Small (Mice) projects present their own problems in relation to RM. You want ' Big Cats'...big enough to make an impact but not too small to go unnoticed.
60-day Drumbeat: Coordinated release, mapped out for each IT Application AND across applications.
Q: How are Key Initiatives for the year determined? How is it decided what goes into a release? A: Top 12-15 executives yearly meet (3 days) to discuss trends, cust sat, etc. Each organization then puts up 12-month rolling plan, which is then communicated to entire staff who then offer what changes will need to be made to meet those plans.
They communicate the release schedule to all employees via their internal portal.
Q: Accomplishment in 2003 slide: How does RM impact these Metrics and Improvements? I'm not quite getting it. These seem like results from the enhancements released, not a result of RM. Maybe I'm being dense.
They have IT Program Managers who work with their 'customers' to maintain the business process improvement maps. Maybe this is their way to get their priorities.
Maybe it's just me, but there is a lot in this presentation, so far, about Siebel and how they measure success than about Siebel's release process. It does show that their CIO has a pretty good handle on what makes the business tic and what his internal customers need in the way of data / analytics, but let's see if this knowledge of the business directly impacts their RM process and strategy.
Upgrade Frequently: They upgrade their infrastructure (Siebel products, 1 instance over 2 load-balanced data centers) up to 10 times a year, which is asynchronous to their 60-day business process improvement releases.
Communication Before / During / After each Release helps smooth the change management.
World-class support, both self-service (FAQ, 2-minute training) and help desk, is key to getting through each release.
Siebel is starting a Application Management Service that will offer their best practices as a service to customer.
IBM, Boeing join forces to seek government IT contracts - Computerworld
Through a 10-year alliance, the companies will develop advanced digital communications and information technologies for current and future defense and intelligence systems. These technologies will be critical for network-centric operations where satellites, aircraft, ships, submarines, tanks, radios and handheld computers share information using the same interfaces, standards or protocols, according to the companies.Chicago-based Boeing has a background as a major military and intelligence platform provider and experience as a lead systems integrator. IBM will provide information management middleware, microprocessor technology, electronics-design tools, software and chip verification technology and more.
These kinds of partnerships between government contractors of the traditionally manufacturing type and IT software / services vendors will be huge as hardware / software / network integration becomes key, especially to the network-centric military. Whose going to partner with who next?
Martin Fowler, author of the widely-cited (and often confused with EA) book "Patterns of Enterprise Application Architecture", takes a stab at why EA efforts led by the IT organization often fail,
The problem for central architecture groups is that they are driven by IT management, but the applications they are looking to organize are driven by business needs. If an application team is told to do work that doesn't benefit their application directly, but makes it easier to fit in the architecture, there's a natural reluctance to do it. Furthermore they have the ace card - the business sponsor. If the business sponsor is told the application will ship four months late in order to conform to the enterprise architectural plans, then they are motivated to back up the application team when they say no (spelled "we'll get around to it later"). Since the application is directly connected to providing business value, and the central architectural team isn't, the application team wins. These wins cause the enterprise architecture initiative to bust.
To avoid this the enterprise architecture initiative has to recognize and submit to the political realities.
Understand what the business value of any enterprise architectural initiative is.
Make sure that any work is supported by incremental short term gains in business value.
Minimize costs to the applications
It's all about the alignment Thing...
Just read a great definition of the role of the EA team in META Group, Inc. - Enterprise Architecture: Answers You Should Have (Meta Account Required),
"EA provides guidance for the selection, creation, and implementation of solutions and related technologies within the context of requirements to meet business strategies."
I'm always looking for these one-liners that work in presentations. And actually, this Meta Practice (EPAS Practice 2110) is good for all kinds of answers to typical questions I've gotten about EA.
Another curious thing I've been thinking about is writing about and linking to things I read by Meta which I know others will not have access to. Will this alienate readers? Will this open up discussion on Meta articles to a community that does have access and wants to write / communicate about it?
On another Meta website note, they do a horrible job of hyper-linking in their documentation on the website. They rarely, if ever, link the numerous references to other Meta Practices / Deltas / Etc. in their documents, leading to frequently frustrating searches and text scanning to find the actual referenced document. Embrace the web!
Business alignment with information technology is a subject that Enterprise Architects should be thinking about daily (even those of us fighting for our rightful place in the flow of enterprise strategic planning info). Maybe I've been indoctrinated too much into the MetaGroup way of thinking, but what I read most among technology people approaching Enterprise Architecture is a scope much smaller than the Enterprise. It seems like it's much closer to the IT Enterprise, focused on a structured, well documented, and reusable technology and application architecture. In those cases, the strategic direction of the business, which should indicate where IT resources should be deployed, seems to get left off the list. And not there's anything wrong with that...it's all a matter of EA scope...but I think it's something different than Enterprise Architecture, or 'holistic' Enterprise Architecture as I've heard it.
An illustration is the Business Aligned post by CityArchitect over at the ITToolbox, where City' gives some scope-increasing techniques to become 'business-aligned' with this as his highest level
"Technique number three in this great alignment strategy is to map Applications to the Business Processes that they automate; we can then relate real Business Transactions to transaction flow in our Applications, and map our Applications to their Host servers and, coupled with Business Systems Management techniques, we can relate System Health, Problem Management and Risk right up to the Business Process. "
I'd have to add a #4 that said that Application development (now called IT Portfolio Management, I believe) that was undertaken based on the strategic plans of the enterprise would be at least a higher level of 'Business-Aligned IT'. It's at least something to talk about.
One more comment on a part of City's very cool post dealing with ever increasing IT Portfolio (which he calls 'base of technology'),
"The reason that this base of technology goes on increasing, is that we don't seem to turn anything off; we don't retire the old systems and technologies. More stuff, more people, more cost, more maintenance."I'd add that another reason for the increasing amount of stuff is that there are ever-increasing 'layers' of Things on top of what we already have, like Portals on-top of our webservers and app-servers or Business Process Managers on top of our exiting EAI or workflow technologies. The 'get rid of legacy' mantra of the past seems to now swung over to 'integrate the legacy (with some new stuff that will soon become legacy)'!
Keep blogging on, City!
There are several very similar reports on the recent GAO report on the Department of Homeland Security's Enterprise Architecture Efforts To Date (Full Report, PDF, 15.3 MB), essentially saying that there are holes in version 1 of the DHS EA, with DHS acknowledging as much but stating that this was time-constrained first attempt (DHS IT budget due 4 months after agencies creation) which layed the groundwork for the next iteration due Sept, 2004. Having a little bit of ground-up EA work under my belt now, I can imagine how hard it would be to produce almost anything without major holes in 4 months.
One major thought this brings to me is the importance of Enterprise Architecture for organizations expecting to grow through merger and acquisition. You must be able to quickly compare the Business, Information, and Technology reference models of both entities to determine the fit and gaps to make good decisions as to m&a viability. EA Programs should provide these models.
Back to the story, the best of the articles on this recent report was Dan Verton's Computerworld one that added in the context of a July, 2004 report from the DHS inspector general stating the EA inhibited position of DHS's CIO, Steven Cooper, seems to be starting from,
"Cooper "is not a member of the senior management team with authority to strategically manage department-wide technology assets and programs," the inspector general's report said. It added that there is no formal reporting relationship between Cooper and the CIOs of major DHS components."My limited experience to date is that unless the CIO (or whoever is running the EA Program, and MetaGroup says this is still the CIO in most orgs) and their EA team is not deeply embedded in the senior strategy setting group in the company, then holistic EA Programs, which include the Business Process and Information Flow /Security knowledge DHS EA V1 got dinged on in the GAO report, are truly going to be disadvantaged and not aligned with the vision of enterprise.
In InfoWorld: Oracle and IBM move BPEL to the BPI forefront, James Borck installs, uses, and reviews (with comparison scoring) the latest business process integration tools from these vendors. IBM's is very closely integrated into Websphere Application Server while Oracle's BPEL-PM will work on top of any J2EE app server (like BEA's Weblogic?). There's lots more information, but here's the summary,
"Both products still have room to grow with regard to improving usability and mitigating complexity. This is an evolving science, to be sure. Yet many of these shortcomings stem from the complexity of XML and the still-ripening state of BPEL more than the underdeveloped status of these products. "I think that these are going to be products used by folks that already have the integrated parts in their environment, not the driver (yet) for putting those parts in your technical architecture.