Death to Boothware.
Technorati Tags: JavaOne
Monday, December 17, 2007
Boothware
I'm doing some reviewing of JavaOne presentations at the moment (SOA/EAI) and the number of vendor presentations that are basically a booth demo where they'd like a bigger audience is just staggering. Sometimes they are dressed up as an "investigation" but most of the time its literally a standard booth demo (even including "how to install" on occasion).
Death to Boothware.
Death to Boothware.
Tuesday, December 04, 2007
Why corporate IT means something
Over on Joel on Software there is a post about his talk at Yale where he warns people not to go into "in-house" corporate development because its soul suckingly bad. Why?
"No matter how cool Ruby is", "Spiffy"?!?! this just about sums up why vendors don't understand their customers. Now most companies I've been in are doing just those sorts of things and are doing it when it makes sense and the people doing this tend to the leading IT lights of those companies. Having worked with lots of product companies as well I can safely say there are legions of developers in those companies who certainly don't have the ability to choose a new programming lanaguage and who are never going to lay their hands on Ajax. So maybe the issue isn't corporate development but the sort of development that Joel did when he was in a corporate.
Now apart from the last bit (which after all is just smart engineering over turd polishing) this does sound frighteningly like average development. There is a bit around never having time to do quality and refactor to your hearts content but that really does miss the point as I've never met a good developer who ever thought what they had produced couldn't be improved.
Ahh I know Joel is talking to students here, but is lying really the option? The best software sells the most? Only if you define best as sells the most. The history of software is littered with examples where better software was ignored for inferior fare. Hell in IT it often seems that we deliberately go for the worst option out of some sort of perversion (C v Ada syntax for instance). The implication here is that product software is the best quality. My experience has always been I've never met a piece of commercial software I couldn't break. Things like having a messaging product, Java VM, Operating system and hardware all from one vendor and it wouldn't work at all not as in a slight issue but as in they could never have tested it because it didn't work in any way whatsoever. Things like vendors shipping software products without decent test tools being available. Things like evil class loader work arounds due to vendor stupidity. Things like Rational XDE which came exactly from people "optimising" (the new stuff is soooo much better and started from a different place IMO).
Corporate in-house software on the other hand is designed to do a specific purpose and when it does that thing it works. There are less edge cases to worry about and you have a defined reason for doing it. Now there is indeed lots of crappy inhouse software in the same way as there is lots of crappy vendor software the question should be really about comparing the best of corporate IT with the best of vendor IT. Now excluding the "found your own IT company" which is always the best if you can pull it off the question is which is better to work for?
Now the problem is that Joel clearly worked at a crappy job in the crappy part of an corporate company. He complains about the pay and conditions and seems to think that software companies always have the best perks. This isn't true for several reasons
Next up Joel talks us through his hell hole job at Viacom. It really does seem that he was a completely unempowered programmer and this is a crap job at any company, where he makes the mistake is thinking that these people don't exist in vendors. They absolutely do and they have many of the same issues. Field sales engineers are good examples, often very talented but having to put up with whatever is thrown at them from the mothership. The point here isn't corporate v vendor but empowered v munchkin, and you don't want to be a munchkin.
So the question in terms of what is best is what sort of impact can a good and empowered person have on a corporate or a vendor? In this day and age I'd say that the impacts are pretty similar. The key is finding what matters. With a vendor company you could take them into a new market and you can do the same in a corporate, with a vendor you could create a competitive advantage over the field, something you could do at a corporate. The point is that these days when decent companies look at changing the game they make sure IT is in that decision. Its a good place to be.
The real reason to me that corporate IT is a great place to work, if you are good and have good communication skills, is that you can actually see what you do make a difference. I'm incredibly proud that I wrote software that means air traffic controllers can do their jobs and be alerted quickly to any collision risks. Now sure the folks who wrote the graphics library and the OS, the software vendors, had a part in it but it was me who brought it together and gave it purpose.
Corporate IT is the point of vendor IT. Vendor IT is there to make money and its the corporates that it predominately gets this from. This means that while as a vendor you can say "look at our shiny app server" or "look at my bug tracker" the only point to your software is if some corporate people turn it into reality. Thus its corporate IT where the real achievement is. Software Vendors provide the bricks and mortar, they quarry the stone and provide you with the rough hewn pieces for you to carve and give purpose to.
The key in corporate IT is to be one of two things. Firstly you could be very talented and looking at real edge challenges (for instance forecasting in retail & supply chain) where you'll have to push the boundaries of technology to the edge in order to stay ahead of the game. Secondly you could be the person tasked with sculpting a result out of all the raw materials of people and the software the vendors provide to create a new solution to a business problem. This is where, IMO, the greatest challenges and talents in IT are. People who can understand technology, people and process and bring them together. Making people think in different ways, using technology in ways the vendors hadn't expected and doing this all successfully to a properly formulated business case. That takes talent.
The majority of the hardest technical challenges I see in IT are in the corporate space. There are of course challenges in the vendor space, especially where the sale is direct to the customer (but is Amazon really IT company or a next generation retailer?) but the challenges in the corporate space are just as large and hairy and often just a lucrative. The hardest challenge in IT however is the same as it has always been, how to take multiple technologies and large numbers of people and deliver a system, changing the business as you do so to make the adoption of the system successful. These are the people who give a point to all of IT and who can point to things in the real world and say "I made that happen".
So vendor or corporate? If you are talented and have good communication skills I'd say go for the corporate. Especially when it comes to the Christmas party.
Number one. You never get to do things the right way. You always have to do things the expedient way. It costs so much money to hire these programmers—typically a company like Accenture or IBM would charge $300 an hour for the services of some recent Yale PoliSci grad who took a 6 week course in dot net programming, and who is earning $47,000 a year and hoping that it’ll provide enough experience to get into business school—anyway, it costs so much to hire these programmers that you’re not going to allowed to build things with Ruby on Rails no matter how cool Ruby is and no matter how spiffy the Ajax is going to be.
"No matter how cool Ruby is", "Spiffy"?!?! this just about sums up why vendors don't understand their customers. Now most companies I've been in are doing just those sorts of things and are doing it when it makes sense and the people doing this tend to the leading IT lights of those companies. Having worked with lots of product companies as well I can safely say there are legions of developers in those companies who certainly don't have the ability to choose a new programming lanaguage and who are never going to lay their hands on Ajax. So maybe the issue isn't corporate development but the sort of development that Joel did when he was in a corporate.
You’re going into Visual Studio, you’re going to click on the wizard, you’re going to drag the little Grid control onto the page, you’re going to hook it up to the database, and presto, you’re done. It’s good enough.
Now apart from the last bit (which after all is just smart engineering over turd polishing) this does sound frighteningly like average development. There is a bit around never having time to do quality and refactor to your hearts content but that really does miss the point as I've never met a good developer who ever thought what they had produced couldn't be improved.
Now, at a product company, for example, if you’re a software developer working on a software product or even an online product like Google or Facebook, the better you make the product, the better it sells.
Ahh I know Joel is talking to students here, but is lying really the option? The best software sells the most? Only if you define best as sells the most. The history of software is littered with examples where better software was ignored for inferior fare. Hell in IT it often seems that we deliberately go for the worst option out of some sort of perversion (C v Ada syntax for instance). The implication here is that product software is the best quality. My experience has always been I've never met a piece of commercial software I couldn't break. Things like having a messaging product, Java VM, Operating system and hardware all from one vendor and it wouldn't work at all not as in a slight issue but as in they could never have tested it because it didn't work in any way whatsoever. Things like vendors shipping software products without decent test tools being available. Things like evil class loader work arounds due to vendor stupidity. Things like Rational XDE which came exactly from people "optimising" (the new stuff is soooo much better and started from a different place IMO).
Corporate in-house software on the other hand is designed to do a specific purpose and when it does that thing it works. There are less edge cases to worry about and you have a defined reason for doing it. Now there is indeed lots of crappy inhouse software in the same way as there is lots of crappy vendor software the question should be really about comparing the best of corporate IT with the best of vendor IT. Now excluding the "found your own IT company" which is always the best if you can pull it off the question is which is better to work for?
Now the problem is that Joel clearly worked at a crappy job in the crappy part of an corporate company. He complains about the pay and conditions and seems to think that software companies always have the best perks. This isn't true for several reasons
- Societal balance - by which I mean women. Tech companies are male domains and the male/female ratio is normally completely dreadful. If you work in a corporate then the odds are this will be much more balanced. This makes for a better social life
- HQs of corporates are better than tech companies. I've been to lots of the supposed "best" tech company offices and the HQ of a pharma, bank, oil company, airline or even traditional manufacturing company tend to be miles better. Now only the best in IT get to be at HQ, but were you planning on being average?
- Flying - The policies at most vendors appear to be "coach unless a VP" whereas in corporates it tends to be "we are in business so we fly in business".
Next up Joel talks us through his hell hole job at Viacom. It really does seem that he was a completely unempowered programmer and this is a crap job at any company, where he makes the mistake is thinking that these people don't exist in vendors. They absolutely do and they have many of the same issues. Field sales engineers are good examples, often very talented but having to put up with whatever is thrown at them from the mothership. The point here isn't corporate v vendor but empowered v munchkin, and you don't want to be a munchkin.
So the question in terms of what is best is what sort of impact can a good and empowered person have on a corporate or a vendor? In this day and age I'd say that the impacts are pretty similar. The key is finding what matters. With a vendor company you could take them into a new market and you can do the same in a corporate, with a vendor you could create a competitive advantage over the field, something you could do at a corporate. The point is that these days when decent companies look at changing the game they make sure IT is in that decision. Its a good place to be.
The real reason to me that corporate IT is a great place to work, if you are good and have good communication skills, is that you can actually see what you do make a difference. I'm incredibly proud that I wrote software that means air traffic controllers can do their jobs and be alerted quickly to any collision risks. Now sure the folks who wrote the graphics library and the OS, the software vendors, had a part in it but it was me who brought it together and gave it purpose.
Corporate IT is the point of vendor IT. Vendor IT is there to make money and its the corporates that it predominately gets this from. This means that while as a vendor you can say "look at our shiny app server" or "look at my bug tracker" the only point to your software is if some corporate people turn it into reality. Thus its corporate IT where the real achievement is. Software Vendors provide the bricks and mortar, they quarry the stone and provide you with the rough hewn pieces for you to carve and give purpose to.
The key in corporate IT is to be one of two things. Firstly you could be very talented and looking at real edge challenges (for instance forecasting in retail & supply chain) where you'll have to push the boundaries of technology to the edge in order to stay ahead of the game. Secondly you could be the person tasked with sculpting a result out of all the raw materials of people and the software the vendors provide to create a new solution to a business problem. This is where, IMO, the greatest challenges and talents in IT are. People who can understand technology, people and process and bring them together. Making people think in different ways, using technology in ways the vendors hadn't expected and doing this all successfully to a properly formulated business case. That takes talent.
The majority of the hardest technical challenges I see in IT are in the corporate space. There are of course challenges in the vendor space, especially where the sale is direct to the customer (but is Amazon really IT company or a next generation retailer?) but the challenges in the corporate space are just as large and hairy and often just a lucrative. The hardest challenge in IT however is the same as it has always been, how to take multiple technologies and large numbers of people and deliver a system, changing the business as you do so to make the adoption of the system successful. These are the people who give a point to all of IT and who can point to things in the real world and say "I made that happen".
So vendor or corporate? If you are talented and have good communication skills I'd say go for the corporate. Especially when it comes to the Christmas party.
Technorati Tags: SOA, Service Architecture
Monday, December 03, 2007
Christmas SOA
I've been reading some things lately that talk about business people being "in control" of process diagrams so I thought it was worth while reprising something I wrote back in 2005 and which is in the book around how there is a big difference between the perceived business process and the actual execution process.
Now I have two kids and its coming up to Christmas and their view of what happens at Christmas is of course completely different to what actually happens. The kids are the business at Christmas its all about meeting their business expectations and goals.
As the parents we have only one job to do and that is to deliver Christmas in the manner the business expects to see it. This means that we have to hide from the business the technical delivery elements and just show Lana and Louis the vision they want to see... now of course the question is how do we deliver an SOA Christmas?
At the top level 0 its all pretty simple all the business wants to see is presents coming from as many different channels as possible.
As the kids are both still young the metric that will matter is volume of presents and its by this that success will be judged.
At Level 1 they have the concept that Santa Claus is the centre of the present giving universe and it is to Santa that the list of request should be made. Santa is then responsible for distributing the list to everyone else for the things he doesn't want to get.
So at a process level the business view is that the list goes to Santa, who sends it on, there is a view that there are things called shops out there involved in some way, but that isn't important to the business. Santa then delivers presents to the stocking while the parents deliver to the tree. Any person coming through the door over this period is also expected to enable the business to get presents.
This is the perceived business process and its this that the kids want to be able to effect. Can the list be delivered in person? Emailed? Sent via some slightly dubious chat service? Or maybe posted the old fashioned way?
So at a process level the business view is that the list goes to Santa, who sends it on, there is a view that there are things called shops out there involved in some way, but that isn't important to the business. Santa then delivers presents to the stocking while the parents deliver to the tree. Any person coming through the door over this period is also expected to enable the business to get presents.
This is the perceived business process and its this that the kids want to be able to effect. Can the list be delivered in person? Emailed? Sent via some slightly dubious chat service? Or maybe posted the old fashioned way? There is a, reluctant, acceptance from the business that the 25th December is the delivery date and that this isn't movable and that some suppliers will miss the delivery date and provide presents at the first available point after the main day. Santa however is never late.
Now the goal of the parents (IT) is to deliver Christmas in the way that the kids expect and to ensure a successful and happy Christmas period.
Unfortunately the parents also know that Santa needs some manual intervention to get things moving. So first of all they have to provision the infrastructure, namely Santa and the Tree, then they have to co-ordinate the present buying to minimise duplicates. A spree of present buying is then underway, as is an increase in debt, followed by delivering the presents in the right manner to the places the business expect them to be.
This therefore is the execution process. This process might get much more complex if you have to add in balancing acts between the business people so there is the perception of present equivalence or if the parents are actually hosting Christmas this year so the workload goes through the roof. This all demonstrates that within SOA, there might be a commonality in an understanding of the services being provisioned, but the actual manner of provisioning and the additional actions are only of interest to the implementors and should be hidden from the business, and other consumers as they are irrelevant to them as long as their objectives are being met. This is one reason why SOA makes good BPM but BPM makes bad SOA
This therefore is the execution process. This process might get much more complex if you have to add in balancing acts between the business people so there is the perception of present equivalence or if the parents are actually hosting Christmas this year so the workload goes through the roof. This all demonstrates that within SOA, there might be a commonality in an understanding of the services being provisioned, but the actual manner of provisioning and the additional actions are only of interest to the implementors and should be hidden from the business, and other consumers as they are irrelevant to them as long as their objectives are being met. This is one reason why SOA makes good BPM but BPM makes bad SOA This is just one of the reasons I tend to say that business process is an IT myth. You need to understand both the business view of what must be achieved (often goal driven) and how it is measured (the implicit process) and then map this down to how IT will deliver that goal and measures (sometimes via an explicit process). In this world of separation its nonsense to argue that the business is "in control" of the execution processes beyond the level of defining the important elements of KPIs, goals and implicit process. Having this explicit process implemented within the services rather than across them (for a blog outline there is chapter on this in the book) also helps to scale as the services are coordinating effort rather than having to have a process per child.
Switching back to more normal IT should the sales director worry that that simple two steps of "check fraud then get payment" might require a complex series of processes and integration to external 3rd parties? Should the LOB manager who wants to get their current key suppliers need to know that this integrates with 20 backend systems and has a complex Master Data Management solution? No that is the reason IT is there to take the business goals and KPIs and best surface them in the way that the business wants. This is why business people shouldn't care about their BPMN diagrams being what are being executed they should just care that they are being delivered.
Remember folks, SOA isn't just for Christmas.
Technorati Tags: SOA, Service Architecture
Accenture still not getting SOA
A while back I pointed out some comments by Accenture's CTO which (for me) indicated that Accenture don't get SOA well they've now established a venture with BEA and it appears that Accenture still don't get SOA.
Wow its still impressively wrong. Hands up everyone who has seen BPEL used in a commercial environment? Does that feel like the fourth and final phase of SOA to you? No me neither. This really is dreadful advice on what SOA is and what SOA maturity is about. I've worked with customers where their first technical SOA project was all about using BPEL (without an ESB) to do something where that made sense.
You can take what Mr Rippert is saying and easily replace WS and XML for some other basic form and an EAI tool, then have that EAI tool be the ESB and put a process engine on the EAI suite. In other words his vision is from a functional and conceptual perspective equivalent to EAI.
If SOA, or any IT change, is just about a series of three and four letter technical words then it will deliver almost no benefits. So has to be about changing the way people think or its pointless.
He [Accenture CTO Donald Rippert] described the four phases of SOA implementation, which begins at using XML as an interface, then implementing legacy systems as Web services, and then using an ESB to connect Web services and use composite processes. The fourth phase involves using BPEL (Business Process Execution Language for Web Services) in which a business application is revised by making changes to the process model rather than the code.
But SOA, for the most part, is not enabling this yet, said Rippert. "Maybe someday, but not today; I don't see it today," Rippert said.
Wow its still impressively wrong. Hands up everyone who has seen BPEL used in a commercial environment? Does that feel like the fourth and final phase of SOA to you? No me neither. This really is dreadful advice on what SOA is and what SOA maturity is about. I've worked with customers where their first technical SOA project was all about using BPEL (without an ESB) to do something where that made sense.
You can take what Mr Rippert is saying and easily replace WS and XML for some other basic form and an EAI tool, then have that EAI tool be the ESB and put a process engine on the EAI suite. In other words his vision is from a functional and conceptual perspective equivalent to EAI.
If SOA, or any IT change, is just about a series of three and four letter technical words then it will deliver almost no benefits. So has to be about changing the way people think or its pointless.
Technorati Tags: SOA, Service Architecture
Subscribe to:
Posts (Atom)