Discussion on:
View:
Show:
Has your organization started building a services architecture? What are some of the benefits you've seen so far?
I've been building them since '91, SOA is nothing new other than the protocols have standardized and the paradigm has gone mainstream.
And, the benefits are many:
1. Generally, shops know their data flow better, because you have to know it to effectively implement SOA.
2. ROI. Legacy apps are reused, with the SOA messaging/middleware being the glue between legacy systems and external actors.
3. Agility - if done well/right. Business process agility is a benefit, e.g. move the request from our external SystemX.ServiceA to partner/vendor SystemY.ServiceB. Also, if done well/right, technical methodology is more agile in how to define/develop/deploy and maintain them.
The truth is, SOA is nothing new. There's 25+ years of experience to draw on pre-marketing buzzword "SOA". It's a very good idea to find the technologies/paradigms/practices in place long before it went mainstream, because there are still nuggets of good info/experience that SOA marketing blitz don't include. (e.g. EA didn't start SOA, in whole, the process control world has been standardized on service-oriented paradigm for decades).
And, the benefits are many:
1. Generally, shops know their data flow better, because you have to know it to effectively implement SOA.
2. ROI. Legacy apps are reused, with the SOA messaging/middleware being the glue between legacy systems and external actors.
3. Agility - if done well/right. Business process agility is a benefit, e.g. move the request from our external SystemX.ServiceA to partner/vendor SystemY.ServiceB. Also, if done well/right, technical methodology is more agile in how to define/develop/deploy and maintain them.
The truth is, SOA is nothing new. There's 25+ years of experience to draw on pre-marketing buzzword "SOA". It's a very good idea to find the technologies/paradigms/practices in place long before it went mainstream, because there are still nuggets of good info/experience that SOA marketing blitz don't include. (e.g. EA didn't start SOA, in whole, the process control world has been standardized on service-oriented paradigm for decades).
I wonder what kind of technology did you use in 1991 to define blocks of software which have business meaning, what kind of technology did you use to organize them into building blocks of the business processes, and how did you create an architecture where these building blocks could be reused and replaced with new versions without disturbing the 'rest' of the systems?
I'm really curious. And I'm a little bit skeptic, too. The idea of reuse has the same age as the programming itself. But the possibilities to implement it started only several years ago. The idea of being able to fly has the same age as the humankind itself. But the possibilities to implement it started only several decades ago (not regarding Daedalus and Icarus)...
I'm really curious. And I'm a little bit skeptic, too. The idea of reuse has the same age as the programming itself. But the possibilities to implement it started only several years ago. The idea of being able to fly has the same age as the humankind itself. But the possibilities to implement it started only several decades ago (not regarding Daedalus and Icarus)...
The roots of today's interest in replacable and reusable goes back to the 1960s. The first time I ever replaced one module with another was in 1969.
I'd recommend you read more about the history of computer science.
I'd recommend you read more about the history of computer science.
Your first sentence is in my post, too, I'm happy you agree with me.
The second sentence is more interesting. Could that module perform a complete business function (I mean the uppermost (application) level of the OSI interconnection model)? And had this module more than one "clients" which used it? If both answers are "yes", then congratulations, you did SOA in 1969!
If any of the answers is "no", then, well... I won't be so rude as you so I won't give you an advice to read more about nowadays architecture and technology...
The second sentence is more interesting. Could that module perform a complete business function (I mean the uppermost (application) level of the OSI interconnection model)? And had this module more than one "clients" which used it? If both answers are "yes", then congratulations, you did SOA in 1969!
If any of the answers is "no", then, well... I won't be so rude as you so I won't give you an advice to read more about nowadays architecture and technology...
- Keyboard Shortcuts:
- Prev
- Next
- Toggle









































