Is anyone actively using the RSS connector CRM? If so, how are you using it and did you customize it any way? If not, what are the reasons for not using it?
This is really for my information. The CRM team might watch this space and have some desire to use the information, but that's not why I'm asking. My new team is looking at some related technologies and we're / I'm wondering how this one fit.
Jim Whitescarver replied to a very old post I made while ranting about distributed software, SOA, and object-oriented development. I wanted to post this directly instead of letting it disappear in the background that are blog comments.
Let me preface this by saying that I think we're talking about different aspects of the same problem and that we're probably more in agreement than not. The primary point I was trying to make in my post was that people shouldn't write consumer applications that assume a web service has a stateful, connected, transaction-supporting, object-oriented interface. On the flip side, service authors shouldn't write services that are stateful, connected, transaction-supporting, etc.
Granted, exposing existing objects or object-oriented systems using a service-oriented pattern is one of the great things about SO architectures. The model provides for cross-platform and interoperable access to existing applications. This is goodness.
Indeed, it is clear that most people that design web services seem to have no interest in exposing objects at all. But does that mean using web services to expose objects is a bad thing? I don't think so.
The point is that there are two distinct applications of web services in the enterprise. Exposing services, and exposing objects. Exposing objects rather than services is often a good idea. Exposing a public interface to an object as a web service is an easy to employ feature of many web service tools. The web service is then simply a technology neutral RMI where the XML is just a serialization of the invocation and response which may be totally transparent to the programmer.
This usage can be valuable in providing real object access across heterogeneous systems and between implementation languages.
If you can really avoid independent object environments that require some coordination then perhaps EJBs alone will work. You may never need to access a your EJBs from Perl, VB, over the Internet or other environment. Web services is certainly not the most efficient way to communicate.
I do get your point, and agree. I just wanted to point out how web services can be used to make systems more object oriented and give ubiquitous access to real world objects rather than each environment having its own unsynchronized independent representation of common objects.
I do not mean to be contrary here, but I do like to consider both sides of these sort of issues deeply. We should not overlook this mechanism if it can simplify the integration of our systems.
Agreed Jim, and thanks for the comments.
I've started thinking again about how to release software quickly. This isn't anything new to me, I've spent a long time with several start-ups working out the details of getting a release into customers' hands, getting their feedback (sometimes immediately), and getting the next release moving. This doesn't seem to be rocket science, there isn't a lot of hard work involved, and there shouldn't be any heavyweight process.
Why am I bringing this up? I have this sneaking suspicion that it's not really possible to release software quickly if you're releasing it under the Microsoft brand. The folks in MSN, Windows Live, and Office Live will likely take issue with that suspicion. In fact, they're out to show the world that Microsoft can release relevant software quickly. I live in a different part of the company where we feel the brunt of long-cycle upgrades. That is, our customers typically buy a product and sit on it for somewhere in the seven-year range.
Now, don't get me wrong, I'm all for buying a piece of software and realizing that investment over something longer than 12 months. And, I sincerely believe that software manufacturers can make that model work very well - they can make money, the customers get new features, and everybody is happy.
But, I've been working on a "new" software delivery model recently and it's all about speed. We are trying to define the product, build enough of it, and get it into customers' hands on very short development cycles. What hit me was the amount of non-essential work necessary, within the confines of Microsoft, to actually release that product. We have so much process around the edges that we can easily overwhelm the actual development time.
Sure, this is a tax that we pay for different reasons: legal issues, security, trademark, copyright, sustained engineering, globalization concerns, and so on. This is the price we pay (and there are more taxes, these are the ones that jumped to mind) to get a piece of software out the door. So, if we're talking about a one- to three-month development cycle, then we're looking at somewhere around six months to release whatever it was that we built (Charles calls this "turning the crank" and claims it's a fixed cost regardless of the project size). With that tax, is it even possible to get on a fast-release train?
Maybe I'm wrong, maybe this is just the view that I've had releasing six products over my Microsoft career. If I am wrong, then let me know what I can do to make the process lighter. If I'm not wrong, then let's work together to see what we can do to ease the release tax.
As part of my masters degree capstone project I'm putting together outlines of all the courses that we would consider core and elective. SU had a 3-course computer security / information assurance track. We were looking over the "catalog" yesterday and realized that we still had a class called "Software Security". It's description talked about how to write secure code. Well, this is a software engineering program and we assume that students want to know more than implementation details.
We have a number of topics that we'd like to cover in 10 sessions (30 hours). But, we're still trying to get a better idea about what industry might want to see. Here's the list so far. If you have any thoughts, add it as a comment. I really appreciate any input.
Information AssuranceEncryptionWriting secure codeStandardizationProcessesDesigning for security
We've all been through the talk about how building software is like building buildings. That somehow there's a correlation between creating a software model of reality and a physical model. I've even given presentations and taught course material that made comparisons between how we build buildings from the ground up with a plan and that we should do the same thing with software.
I'm sure we've all heard the flip-side of the same discussion which says that software architecture is somehow very different from building architecture because software is mutable. That is, if we get parts of it wrong today we can go back and fix it.
For the most part both of those arguments seem to hold. We want to build software with a plan and on a stable base. We build buildings that way and things turn out well. Right?
I noticed a difference last night when I received an invoice for "additions" which were made to my house. For those of you who don't know, I'm in the middle of a huge remodel project; this invoice was, I had assumed, my monthly "catch-up" payment against the original bid.
So, what's different between the two worlds. Well, in both software and buildings estimates can be incorrect. We don't always have all of the information we need so we make guesses. That's why we call the estimation process an estimate. It's not an exact science. At least it's not in the software world.
We've been building homes for many, many years now and we know a priori what's going to go into their construction. In fact, most building estimates are extremely close, which is why I was making monthly payments against the estimated cost and schedule. Well, I realized last night that it's entirely possible to have an immediate 20% cost overrun building a house (or remodeling one as it were). Why did this happen? Well, turns out that the architect hadn't done all the planning that typically goes into a house remodel plan -- he forgot three windows and ALL OF THE LIGHTS.
What's this got to do with software? Well, in software we learn things as we build the product. We do this because it's not possible to know everything about the product before we start building it. Cost overruns happen, and when there's doubt about the cost to build a feature developers even over-estimate to cover their asses and their customer's asses. Building architects never over-estimate. Ever. Not once. They always figure out everything they need to put into the project and everything "new" after that is a change order. They can get very good estimates this way and everybody comes out happy in the end. Unless the architect forgets ALL OF THE LIGHTS.
Charles Eliot stopped me in the café at lunch today and asked me to clarify my comments about why direct database access in MS-CRM is a necessary evil. Actually, I think I used the phrase "evil-but-absolutely-necessary" when I described the design and implementation of filtered views.
Way back when the CRM product was in design we had a few ideas about how the database should look. One camp took a very esoteric, but correct, view. The other had a highly normalized and simplified view. The latter design was chosen. One of the core tenets of that design was its inherent readability. Not necessarily readable by average users, but readable by people who'd have to write those "special" reports that the system didn't provide.
Why does this matter? Well, because the idea was that the database should be accessible and not locked away. I always believed, and still do, that the data and the database belong to the customer and they can do damned near anything they want. We wrapped the database in a user-protective layer called the CRM platform and asked that anybody wanting to write to the database go through that layer. We never said you couldn't read directly from the database though.
What we did say, although I suspect the written word is a little light, is that we reserve the right to modify the data structures on a release-by-release basis to provide greater functionality, faster access, bug fixes, and so forth. I even went so far as to say that we would break any application written which bypassed the platform layer, and I said it in public several times.
With the release of 3.0 and the exposure of filtered views we still reserved the right to break any application written on those views. Only, in this case, because we released the bits as a "feature" and then started talking that same feature up, we got ourselves into a situation where breaking applications isn't a great idea. In short we said "go ahead and use the filtered views, they're good for you". But, we didn't look far enough into the future to see what effect that would have on innovation.
So, I stand by my comment. The filtered views, and by extension direct database access, is an evil-but-absolutely-necessary thing. It can't go away. It probably can't even change significantly. But, I expect those views to morph over time as new schema concepts are introduced.
On continuous loop for the last few days is Zero: A Martin Hannett Story. It's a must listen for any fan of Mancuncian music from the late 70s and early 80s.
Note: free exposure to CRM team members' blogs.
Charles Elliot, a good friend and recently a co-worker of mine, has finally jumped into the blogging world. Knowling Charles I'm expecting a lot of goodness to come our way. In particular, I'm waiting for him to start talking about music and his take on it.
In other news, the CRM PM team has a new blog. I suspect they'll stay pretty much in the "supported" world and will talk to you about all things CRM V3 and what they're planning for future releases. As I've been steering clear of the CRM world for a few months now I'm not sure what goodies they'll talk about first (although I see Charles has posted something about the, IMO evil-but-absolutely-necessary, direct database access exposed in V3). It'll be very interesting to see what the CRM PM team blogs about that's not blogged about on other CRM PM team member blogs.