SDA India is an online resource for Software, Development,IT, Architecture, Open Source, Mobile, Security, Databases, Delphi, C, OS, Asp, .Net, Php, Xml, Java
Planet SDA-India
I dragged myself to Redmond last night to attend Microsoft’s Fifth annual SOA and Business Process Management (BMP) conference. First, Microsoft states that it will not be designing and announcing its own enterprise service bus but will in fact allow customers to leverage whatever service bus(s) they already have. This sounds the same as HP’s philosphy towards ESBs. Second, the world of technology is based on a federated model (I agree). Given this philosophy, Microsoft is now talking about the Internet Service Bus — a publish/subscribe model for interoperability that leverages existing middleware. This is being offered as part of BizTalk Server and is being offered as a hosted cloud service by Microsoft. Third, Microsoft is making two big bets: a service orientation to creating applications by expanding and exploiting existing technology and providing hosted services via a set of cloud services that act as an integration framework. If customers want, they can move hosted services back to their enterprise. Providing shared models that can go across. Fourth, Microsoft is making its entire plaform model driven that is backed up by a SQlServer based repository. This becomes a general purpose modeling platform with a set of tooling.
Microsoft Announces Major SOA Initiative, And a Whole New Wave of Innovation
Brian Loesgen
| Link to this blogEvery once in a while an announcement happens that has the capacity to profoundly change the rules. I still remember clearly reading the initial press release in 1999 about this new thing from Microsoft called “BizTalk”, and, I remember telling a co-worker that I was going to keep an eye on this new BizTalk thing. Here I am, 8 years later, still deeply immersed in the world of BizTalk. I would rate Microsoft’s Oslo announcement today as being equally important. It is an ambitious undertaking, one that changes the rules for .NET developers. For me, this is déjà vue all-over-again with that 1999 press release, with the significant difference that this is an evolutionary change, and the reach will be far greater, touching most .NET developers.
My definition of Business Service Management (“BSM”) is derived from my recent experience as the Global CTO for one of the largest private equity companies. In this role, I continually saw that each of our seven + data centers, as well as, in the IT operations of most of our portfolio companies the proliferation of siloed point solutions each covering two or less of the elements of a critical service. For example: In one of our Asian data centers we had three network management products, eleven host or device-oriented point tools, five network monitoring products and at least five security products. Most of these were either not being actively monitored or they were not adequately performing the function in which they were purchased for. For that matter, three of these items were not even installed (“shelfware”)...
James Taylor reacted to a posting about the importance of good Requirements. He sees process as something else than requirements. And he advocates a clear seperation of the concept of Rule and Requirement. First on the process part vs requirements. I see a process as a specific concept in requirements. It can be requirements towards a business: (1) This is the way I want our people to perform this process (a business requirement) Or it can form part of the requirements to a system (a software requirement) (2) This is the process I want the system to follow when processing claims. Or a mix of course. So, is a process definition a software requirement? Sometimes.
"Back when I was on the Architecture Committee, the developers never listened to me. But, now that I'm Enterprise Architect, I'll show them. I'll put in so many governance policies that they won't know what hit them. And there's nothing they can do about it - because these rules are good for our company." OK, I exaggerate a bit. I know a lot of great enterprise architects that would never think this way. But, I wanted to illustrate my point: In life, the most effective policies are supported by both carrots and sticks. Speeding on the road? Your insurance company gives you price breaks if you don't get caught, and the government gives you fines if you do. Carrot and stick. So, what does this have to do with SOA governance?...
Non-proprietary software development received a thumbs up from investors with Spring framaework creator, Interface 21, securing a USD 10 million funding from Benchmark Capital. Benchmark has previously invested in RedHat, MySQL and JBoss [which was eventually bought by RedHat for USD 420 million in 2006]. Spring is an open source web application framework for the Java platform. It was developed as a light-weight solution to make Java coding more flexible, easier, and competitive with other languages like RoR (Ruby on Rails). Unlike other heavy-weight APIs Spring is modular, meaning you can use parts of it; for example, like a bean container with Struts on top of it, or use only the Hibernate integration or the JDBC abstraction layer. Dependencies on the framework can be minimal, depending on the area of use.
Just came back from an all-day offsite with the EA team in Microsoft IT. It occurs to me, in speaking with my collegues and in side conversations, that we have a good idea of what Enterprise Architecture is, and how it benefits the company, but many of our stakeholders do not. That's not to say that we are perfect, or that other people should just "guess" our value. The Value of EA needs to be carefully tailored to fit the actual needs of the organization and we have to do a good job of making that value visible and sharing it with others. On the other hand, I know that some good folks in both business and the rest of IT have different impressions of what "enterprise architecture" is and what it does for an enterprise. Some may feel that the value of architecture is to design the solutions that the company needs to consume (build the solutions right!). The real value, in my mind, is to help make sure that the money spent on IT is building agility and not complexity (build the right solutions).
