Blog

BizTalk, Design, SOA

BizTalk and Big Design Up Front

Some companies seem to think that doing a Big Design Up Front (BDUF) before starting out implementing a BizTalk solution is the way to go. However it isn’t a BDUF from the aspect that they first would like to go through all their requirements and then through a waterfall style design phase for all of the requirements they have in mind. Had it been BDUF it would have been bad. now it’s worse. They want to install an all purpose integrations plattform with full support for BPM, Human Workflow and Governance from day one.


Although I’m not an agile fanatic of any sort, I just don’t believe that should or can be done. You can’t just decide on all the pieces you wish you had in your infrastructure and go out and buy them and think you will get the benefit of those pieces included with the purchase. For that matter it’s not even certain the pieces you think you want are the pieces your business really needs. And what’s worse, doing so is a fast way to waste a huge amount of money. Although they are all great products, you just can’t put what you needed for that – SQL Server, BizTalk Server, MOSS, K2, SOA Software and a couple of other products – together from day one when starting out establishing a new integration plattform. You are smart if you start small. Integration is about being agile, BizTalk is about being agile. Being able to exchange one product for another whilst not impacting the rest of the systems within the company. You can’t just install an enterprise architecture because you want to “start doing SOA”. Sorry to those of you missing out on all that juicy license money 😉


Now with that said, you can do a BDUF if you wan’t to. I believe there are sitiations where that method works, although I think a slightly more agile approach is more likely to succeed. But even if you do, don’t translate that design directly over to products and a Big Bang install and think you’re there. It’s just not that easy.


I was thinking about this while building lego with my son recently, and I took this picture. You can draw your own conclusions as to its meaning.

BizTalk, Configuration

Q: Can I run BizTalk Server 2006 R2 on Windows Server 2008?

Q: Can I (should I) run BizTalk Server 2006 R2 on Windows Server 2008?
A: No. And these are the main resources I give customers who wants to see some kind of Microsoft reference to this:



Q: Can I (is it technically possible to) run BizTalk Server 2006 R2 on Windows Server 2008?
A: As I mention (but perhaps do not emphasis) in the answer to the first question of this post “Can I (should I)” is an answer directed at customers. From an technical aspect it is possible to install and run at least the main parts of BizTalk Server 2006 R2 on Windows Server 2008 (see this post), however it is not supported. As such the answers to customers is (so far) still no. But then again up until quite recently it wasn’t really supported to run BizTalk Server virtualized on VMWare either (but now it is) and we still did that so maybe I’m being over-cautious? It’s not the same kind or level of support we are talking about though…


Q: Can I (should I) run Windows Server 2008 as the host OS on which I run virtualized guest OS with BizTalk Server 2006 R2 though Hyper-V?
A: Yes. As long as the guest OS is compatible with BizTalk Server 2006. Ie Windows Server 2003 (, XP or Vista). See the BizTalk Server 2006 R2 Hyper-V Guide.


UPDATE: I updated this post after comments. Thanks Jocke, it’s certainly more complete now.

Uncategorized

Hit the ground running WSE Adapter Links

Recently I had the (questionable) pleasure of working with the WSE Adapter for a POC on a BizTalk Server 2006 Environment. I thought I’d post my shortlist of links to enable you to hit the ground running if you find yourself in the same situation:






  • Of the things you can access from that site the most interesting one is the WSE Adapter Walkthrough.


  • There are also links to the WSE Adapter Download, as well as SP1. You have to run them both.


  • As a pre-requisute you need WSE 2.0 SP3. SP3 is one download which you can run directly. To be able to run the Walkthrough you need the full version, but for servers you can just get the re-distributable (which is also included and installed as part of the full version that also contains the SDK and Visual Studio .NET functionality).


  • Although Visual Studio integratation is included this is intended for Visual Studio 2003 and won’t do you any good if you are running Visual Studio 2005. There is no service pack for that. But then again you neither need or miss it.


  •  

General, Learning

Pragmatic or passionate? – part 2

To me there are four distinct type of developers. There are the day-job developers, the lazy developers, the average developer, the programatic developers, and the passionate developers. These are the main types by my definitions.


The day-job developers are the ones that don’t care about what they do. They might not even like what they do. They still do it. They might reason that it’s a decently paid job, with good benefits and a high degree of freedom. At least that’s the case for most of the people employeed within the IT industry according to one of swedens IT newspapers (see link (in swedish)). This kind of developer never learns anything not shoved down his throat (in one way or another). Either by necessity to complete the task assigned or when attending some course he was sent to by his employeers (because he would never actively attend a course – unless perhaps for the chance to get up later in the morning and get home earlier in the afternoon). Even when it comes to completing a task this type more often then not asks someone else how to do it, then does it, instead of finding out for himself.


The lazy developers don’t do anything they don’t need to. What makes them any better then the day-job developers is that they actually have an interest in what they do. Not enough to make them work to get do anything outside the box (ie their assignment) but they still enjoy going to work and like what they do. They will happily attend courses, and even look ones up themselves, but they still don’t put in any effort outside of their job. It’s not that they are not interested enough, it’s just that they can’t get over the threshold of knowing how to start. When assigned a task they can’t handle the lazy-developer will try to find out themselves, but it will probably take them awhile since they are not accustomed to seeking out information, and they don’t know enough to really know where to look.


The average developer understands that he must evelove to stay attractive. He must learn as the industry changes. As such he will happily attend courses, seminars and read articles. He might not spend all that much time doing it outside work hours, but he will try. If there is, say, a usergroup, he will attend to learn more – because there will be someone else there to feed him information. As such he knows a bit about the industry trends, enough to know which articles and/or books to read, for example on the subway to and from work (maybe not as a daily routine, but when he finds something new and interesting). When faced with a task that he is unaccustomed to he will search for guidance and help in an effective maner, but there is still many areas with which he is unfamiliar. The average developer is more often then not specialized, and can’t go outside the frame too much, at least not without quite a bit of work – but he is not afraid or unwilling to take on new things.


The pragmatic developer is experienced. He has done the things he has read about or attended a course on. He sets himself apart from the average developer by having “been there, done that”. That doesn’t have to mean that he has necessarily done real world projects on all the topics he knows. Some he might only know in theory, but that’s enough to make him proficient in finding solutions to new problems in new areas. His knowledge spans a wider area then the average developers since he tries to learn more and new things as much as possible (see my previous post on prioritizing). More likely than not he has an area within which he is specialized, but he has a general understanding of a much wider area and are comfortable discussing most of the terms and concepts found within the industry.


Now the previous type sounds like a pretty decent one. One that I’d like to work with any day. What more could you wish for? I don’t consider there to be a category such as a complete developer, ie someone who is the pragmatic programmer and on top of that has the depth of knowledge that matches the specialists level on all or most of the topics available within the industry. There are a few people I would consider putting on that level, and I envy them, but they are too few to form a category, they are more of an exception that confirms a rule then anything else.


So the passionate programmer then? What sets him apart from the programmtic programmer? I’d say two things. The first is his strong desire too always learn more. He may still have priorities that contain other things, but he is passionate about learning more. He not only understands that he needs to learn more to stay ahead, he does it because he enoys it. The second thing is that he doesn’t do it all for himself, or the project goal he’s currently pursuing. He likes to share. He does his best to make others learn what he knows, to spread the word. This doesn’t necesarrily mean he’s a trainer, or organizing usergroups for that matter. It might be in a smaller scale. Not all passionate programmers are forward enough, or comfortable to be presenting to large groups. But the desire to share is there.


Now granted there are more to it then this, more aspects. Like knowledge about business, entrepreneurs, people with new ideas, carisma, naturally outgoing people as opposed to naturally quiet or nervous people. People that really stand up for the team as opposed to those who don’t. Ok, so where does the arcitect fit in? Etc… But the above categorization is one way to mirror the differences I see in how developers work in regards to their competency. I decided in part to write these posts after listening to an MSDN podcast (in swedish) featuring Patrik Löwendahl and a conversation we had with Johan Lindfors. There is also an article on the swedish forum Pellesoft written by Johan Normén here. It’s an interesting topic – this is how I see it.

Uncategorized

Pragmatic or passionate? – part 1

I’ve read, listened to and been in a few discussions lately about competency, or the rather the different kinds of developers – as in the diverse approach they have to their day job. I thought I’d give my view, compacted as it must be in a blog. I’d be more then happy to discuss it further with you through comments, email or in real life.


Going back a few years, say to the year 2000, I felt pretty comfortable saying I knew Microsoft development, and by that I would mean that I knew enough (on a sufficient depth) of all the products and technologies that were used in any greater extent in a common development project. It’s no secret to you who were active at the time that if you knew SQL, VB6 server-side and ASP together with a little javascript and CSS and could do C++ and COM related programming, and now and again a little XML, then you could pretty much step into any project and be productive as a programmer from day one.


Today the scene is widely different. If you can honestly say that you know every product and technology that is featured within an arbitrary project built on a Microsoft foundation then one of two scenarios are true. 1) You have devoted your life to being a developer and everything revolves around it. 2) You feel always unsufficient, neglecting other tasks and/or family and non-developer friends. You spend what feels like too much time trying to learn, but it never seems like enough.


With that said most of us don’t fall into those categories simply because we acknowledge the fact that we don’t know everything about everything. Note: If you at this point are thinking that ‘Hey, I know everything, but don’t recognize this’ then hey, you’re either a genious – and I salut you, or you’re delusional. The range of things to know is just too big. And it’s not just technology. Apporaches to programming (ie DDD, TDD, BDD etc) and running projects (ie Agile) as well as other surrounding topics have become increasingly important as the industry has become more mature.


So instead you prioritize, specialize in a few topics and purposefully filter through articles so as to not spend time reading in-depth topics (however interesting they may seem) about (for you) non-essential products and technologies. I might for example find an in-depth article about the search engine plugins and optimization for MOSS 2007’s enterprise search engine to be a very interesting topic, but will prioritize, and instead read something I feel is closer to what I do, such as how the UDDI 3.0 integration with BizTalk Server 2009 is built or an introductory article to WebMethods even.


This prioritizing to me is a pragmatic approach. You just can’t read it all, do it all, know it all – so you have to be pragmatic. But that doesn’t mean you’re not passionate about what you do. Writing this I had to prioritize, so this became part 1 and other parts will have to be a later issue, now I have other things to do…