Showing posts with label SOA. Show all posts
Showing posts with label SOA. Show all posts

Friday, 29 June 2012

How CEP will make SaaS the killer app


I got the insight at TIBCO's Transform event I blogged about yesterday - how we can finally solve the Customisation Riddle we've been unsuccessfully combating in IT for decades.
Software as a Service is breathing down our necks and guaranteed to replace quite a few on-premise apps in this decade alone. Starting with your tertiary (cleaning, reception, catering, leasing) applications and also your secondary ones (reporting, payroll, timesheets and maybe even some HR), it is likely to halt at your primary systems that support your core business

Why? Because the need for exceptions increases between the three types. Yes you can customise your SaaS and many will do so in the beginning, but it will only make your SaaS more expensive in the end - someone has to foot that bill.

Tuesday, 22 May 2012

Simple Service Enterprise - part 6


In my latest post, I recapped on the previous posts and started to take Integration from a business point of view. I'll continue to do that here, and try to mix in technical details without it getting too confusing. Wish me luck!

Here's the conversation again:

Friday, 11 May 2012

Simple Service Enterprise - part 5


In my first post on SSE I explained why and how I want, and can achieve, and have achieved, an Enterprise Integration paradigm that will give you a device-agnostic, platform-agnostic, tool-agnostic architecture that will free you from being crushed by the two tectonic plates in IT at the moment: diversity in devices, platforms and tools on the inside, and diversity in devices, platforms and tools on the outside

In my second SSE post, I explained why the approaches of the last decade and more (XML, ESB, SOA and SOAP) have failed, and in my third post I dared to state that REST is never ever going to be a solution to solve the issues either.
The reactions I got to that mainly showed me that myopic perceptions persist across techniques - yet replacing SOAP by REST and XML by JSON without questioning the business value of any of those is now being undertaken by the most zealous, and I simply won't have it. Not on my watch

Wednesday, 9 May 2012

Simple Service Enterprise - part 4


Today we'll take a REST from REST and I'll touch upon one of the issues I ran into today: the two types of data there are. REST assured however that at least a few of the next posts will be about yesterday's topic, as it has led to fierce debates here and there over the course of the day. Yes, pun intended

There are two types of main data: Master Data and Transactional Data. And both have very different CRUD models, requirements and needs

Monday, 7 May 2012

Simple Service Enterprise - part 3


My previous post showed the fundamentals of information interchange: exposing business functionality, currently encapsulated in the back-end, to the outside world via services. These services are a one-to-one translation to back-end functions, which are one-to-one translations to business process steps themselves: the smallest level of business transaction.
I also showed that the How of exposing these services, e.g. in which format, largely if not solely depends on a healthy amount of opportunism

This post will explain why REST is a bad idea, while taking the previous one a level deeper

Saturday, 28 April 2012

Simple Service Enterprise - part 2


Yesterday's post was about Simple Service Enterprise, and showed the basics: to keep up with the growing diversity inside and outside your enterprise for getting the same functionality on different devices and platforms, you need an Integration layer (the red in the middle). Can't argue with that, point-to-point integration is a neat quick and dirty solution for very small IT landscapes and doesn't scale cost effectively

SOA attempted to do so via ESB, but there a few reasons why that failed:

Monday, 28 November 2011

Asphalt that controls traffic type and flow?


This weekend I attended the SAP Inside track NL event, held at Ciber HQ in Eindhoven. The event was great, and I really enjoyed it but would have loved to stay longer and gotten more involved.
What has followed are great conversations and discussions, new people to follow on Twitter and elsewhere, and lots of topics to talk about

One of the inputs for that is the presentation I gave at #sitNL

Monday, 13 December 2010

2010-2020: The Great Divide


A Great Divide is what I see for the coming decade. Not a hydrological divide of the Americas, but an IT-divide of the business.
Pretty much a follow-up from my one year-old Cloud and Social: the tectonic plates of IT 2.0, this post will show the great challenge Business and IT need to face together to make it through the coming decade: overcoming the explosion of forces that will rip up the foundations of every business: IT as we know it

Tuesday, 26 January 2010

The pitfall of Enterprise and Social: evolution takes place in small steps



Enterprise architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model

Thank you MIT, and wiki!
Enterprise Architecture is a well-debated topic. It certainly is an ambitious goal, and encompasses a rather huge area: the enterprise. One could compare it with city architecture, although those folks usually take a bit longer for redesigning and -building entire cities. In IT, almost everything seems to have to fit into a 5- or 10-year roadmap

Monday, 28 December 2009

The promise of SOA - what has it brought so far?

SOA has been around for a few years now, time to see what it has brought us. Especially since SOA 2.0 seems to be an excuse to us all to forget the imperfections of SOA and hurry over to the next hype, leaving SOA behind in its own rubble

I think SOA is a good concept. IT is bad enough for the business as it is, with all its inherent diversity: one business, a few processes, and dozens or hundreds of applications supporting it. And, since CRM and ERP, we all know very well that the one-size-fits-all promise is yet another Utopia, slowing down your business rather than doing the opposite

Doing SOA the right way


Here are my 4 points:

1. Understand the diversity, and the evolutionary law: everything will always change. You might think that you achieved a lot by homogenising today's mess, but just wait 5 years and then have another look. Thou must always translate - and leaveth that to professionals. There is no one-size-fits-all

2. Diversity as in applications, but also as in languages spoken. In Europe, 2,000 years ago Greek and Latin were cool, then vulgar Latin took over, French was okay since 1600, English rules since 1900.

Architecture as a pressure cooker


Right about now I'm reading about a company that wants an enterprise-wide Service Bus "to glue it all together" (my own words) and create an agile, flexible service oriented architecture (their words)

Now, how well have they thought about the different departments, each dealing with different business pieces, consumer sub-markets, various government regulations, different timings (8/5, 12/6, 24/7) etc?

Not at all. It's all tech-talk. Here's the worst part: The ESB must support SOAP over JMS outside, and SOAP over HTTP inside. Described in WSDL. Now I know exactly what that implies, but the authors probably don't have a clue themselves.

The sudden death of EAI


After decades of more or less succesfully integrating databases and applications, there was a proven model: hub-and-spoke architecture with a canonical model

It was pretty perfect: the evolutionary as-is and to-be diversity of any IT-landscape was absorbed by an almighty interpreter-translator in the middle, who would take all the different languages and dialects and translate them to an intermediate language that would be that enterprise's business language
Just as in the European Parliament, where they call this a 'relay' language. Now, if anyone knows anything about levelling (language) boundaries, it is right there. They handle 23 different official languages

Friday, 18 September 2009

A palace revolution. In IT?


I do apologise for the fact that in this particular blog abbreviations will be flying around like grilled geese in the land of Cockaigne

As described, a palace revolution is about changes in culture, economy, and socio-political institutions

The cultural revolution has been ongoing for decades now, with entire countries wondering about (the state and future of) their culture due to disappearing frontiers on the currency, economical and national border level

We're right in the middle of the economical one with the current crisis

Social media is now invading the earth: 300 million people on Facebook, 50 million on Twitter - and let's not

Saturday, 29 August 2009

JFGI - Just Fluently Globalise It


Inspired by Wayne Horkan's blog series on automated provisioning and triggered by Andrew McAfee's blog on the future I'm wondering what's happened to the initial cheery mood around automated provisioning
And what is it called anyway? Automated provisioning gets 300K hits on Google, automatic provisioning gets twice as much. I prefer the first one though, as nothing in this life is automatic

Can you cloudsource your IT if it isn't ready for automated provisioning? I don't think so, as the whole point of Clouds seems to be the great flexibility in up- or down scaling 'your stuff': SAN, NAS, OS, DB, apps, The Works

Sunday, 17 May 2009

How Cloud computing will drive Enterprise Integration


In a few recently witnessed presentations it was extraordinary to see how two utterly unrelated matters were seamlessly joined together on the same slide

I'm talking about virtualisation and Cloud computing on the one hand, and world-wide-web services on the other hand

These two entirely different worlds (physical iron infrastructure versus logical business functionality) have been more often associated together over the last months, but it seems to be getting a bit out of hand now

How can physically relocating infrastructure give you fully disclosed backend systems? Of course it can't. It will force you to adhere to a few standards here and there, but that's all on the (rather dull) infrastructural level.