JamesBrownIII
asked on
Theoretical question ..
Bicycle component manufacturer UK
The company has a manufacturing and warehouse base making frames for BMXs.
They also manufacture international brands for wheels, seats and tools.
They supply small shops and are building international sales in the EU, US and Japan.
There are 5 sales account executives in the UK working from home(car) and 1 each in Paris & San Francisco.
AutoCad is used to suit each customers specific design (color, graphics, components, etc etc)
Sales account executives define and negotiate the specification with the customer.
Improved communications is needed using the best technology available to enhance communications between sales agents together with speeding up the manufacturing process between design and delivery.
how would u recommend integrating an Intranet to accomodate these things
Thanks for your help
The company has a manufacturing and warehouse base making frames for BMXs.
They also manufacture international brands for wheels, seats and tools.
They supply small shops and are building international sales in the EU, US and Japan.
There are 5 sales account executives in the UK working from home(car) and 1 each in Paris & San Francisco.
AutoCad is used to suit each customers specific design (color, graphics, components, etc etc)
Sales account executives define and negotiate the specification with the customer.
Improved communications is needed using the best technology available to enhance communications between sales agents together with speeding up the manufacturing process between design and delivery.
how would u recommend integrating an Intranet to accomodate these things
Thanks for your help
Get broadband service (DSL, Cable modem, fractional T1) at both locations. Set up a VPN (virtual priovate network) that uses the internet to securely join the networks at the two sites. The simplest way to do so would be to use a good VPN-caoable firewall appliance at both ends, between the "modem" and the internal network.
ASKER
What about web services and actual server software ?
I would recommend NetWare 6.5 using Nterprise Branch Office:
http://www.novell.com/products/branchoffice/
Take a look at this page to see all of the Nterprise line of offerings, many of which are INCLUDED with NetWare 6.5:
http://www.novell.com/products/
http://www.novell.com/products/branchoffice/
Take a look at this page to see all of the Nterprise line of offerings, many of which are INCLUDED with NetWare 6.5:
http://www.novell.com/products/
Also look at this link for examples of how Nterprise tools can work for you:
http://www.novell.com/solutions/nterprise/
http://www.novell.com/solutions/nterprise/
If your VPN is hardware based (all the good applicances ofer this option), then server software is irrelevant. I'm not sure what yu mean by web services. The current IT industry definition of web services is to make use of several system protocols to allow remote data retrieval or code execution by complex programs, usually using J2EE or .Net.
Which is what Nterprise Branch office is, as well as iFolder, iPrint, etc.
ASKER
There are 5 sales account executives in the UK working from home(car) and 1 each in Paris & San Francisco
How could I accomodate these into the system ?
I was thinking using Domino ????
How could I accomodate these into the system ?
I was thinking using Domino ????
I suppose you could use Domino, if you want to write all the stuff.
The solutions from Novell are solutions, not a development platform. Check out the solutions lnk.
How, physically and logistically, to hook them up is another story. If you need them to connect anywhere, anytime, I supose you'd have to figure out a broadband wireless access method, with telephone/modem backup if there isn't coverage where they are. Since you're talking EU and USA, it might involve different technologies and multiple wireless ISP accounts.
The solutions from Novell are solutions, not a development platform. Check out the solutions lnk.
How, physically and logistically, to hook them up is another story. If you need them to connect anywhere, anytime, I supose you'd have to figure out a broadband wireless access method, with telephone/modem backup if there isn't coverage where they are. Since you're talking EU and USA, it might involve different technologies and multiple wireless ISP accounts.
ASKER
ShineOn, what would be your personal advise on a solution that could tie the production engineering and product development team together in real-time ? At the minute communications are poor .. I am not very experienced so any advice is extremely helpful however advanced it is.. thanks
That depends on what you currently have. If you're running a *nix network, a NetWare network or a Windows network. If you have a mainframe or mini running, like an IBM 3090 or an IBM AS/400. What software the two teams use for their primary functions. What software you use for general interdepartmental communications and email. Exactly in which way you want to take all of these pieces and make them work together.
It can be simple, functional and *maybe* not *exactly* what works best. It can be quite complex, functional, and *maybe* not*exactly* what works best.
Oftentimes a custom application has to be written, but it is possible to leverage out-of-the-box functionality combined with establishing and enforcing procedural guidelines and wind up with the best solution to meet your goals.
If you currently use Notes/Domino for your internal and external email, but don't leverage the collaboration functionality, then Domino may be your best choice to tie it all together, including your sales force. Keep in mind though, that it is likely to become a development project for some Notes developer.
The Novell products can tie it all together with various communication and collaboration tools that might need some customizing, but most of what you'd want to customize would probably be the web interface. You could supplement that by having a custom web-based app, using open-source, standards-based tools like Apache, PERL, PHP, etc., front-ending a database that would track an order from sales through engineering and development, into manufacturing.
It depends on what you want to spend, what direction you want to take your technology, and how much you want it to cost to run and maintain. Without being intimate with your company's current technology status and work flow processes, that's about all I can say.
It can be simple, functional and *maybe* not *exactly* what works best. It can be quite complex, functional, and *maybe* not*exactly* what works best.
Oftentimes a custom application has to be written, but it is possible to leverage out-of-the-box functionality combined with establishing and enforcing procedural guidelines and wind up with the best solution to meet your goals.
If you currently use Notes/Domino for your internal and external email, but don't leverage the collaboration functionality, then Domino may be your best choice to tie it all together, including your sales force. Keep in mind though, that it is likely to become a development project for some Notes developer.
The Novell products can tie it all together with various communication and collaboration tools that might need some customizing, but most of what you'd want to customize would probably be the web interface. You could supplement that by having a custom web-based app, using open-source, standards-based tools like Apache, PERL, PHP, etc., front-ending a database that would track an order from sales through engineering and development, into manufacturing.
It depends on what you want to spend, what direction you want to take your technology, and how much you want it to cost to run and maintain. Without being intimate with your company's current technology status and work flow processes, that's about all I can say.
ASKER
Windows 98 and Office 2000
No REAL technology in place. Cost is no object so there fore the technology can be advanced
No REAL technology in place. Cost is no object so there fore the technology can be advanced
If you do not currently have Notes/Domino in place, I recommend you start with checking into the Novell solutions I posted, and extend from there using internal procedures as a good, solid first step, that fully supports Internet standards and embraces the open-source community.
From there, I'd say you should consider the concept of expanding your intranet/extranet using open-source tools and products. It should not be hard to find people that will write what you need, and you will be starting from a foundation that is built on security, reliability and supportability. You can end up with a really slick system that tracks an order from concept through delivery if it is designed right, and all using industry standards and open-source tools.
Having Novell's eDirectory as part of your infrastructure will give you excellent administration and great identity management and security.
My opinion, take it as you will.
Good luck.
From there, I'd say you should consider the concept of expanding your intranet/extranet using open-source tools and products. It should not be hard to find people that will write what you need, and you will be starting from a foundation that is built on security, reliability and supportability. You can end up with a really slick system that tracks an order from concept through delivery if it is designed right, and all using industry standards and open-source tools.
Having Novell's eDirectory as part of your infrastructure will give you excellent administration and great identity management and security.
My opinion, take it as you will.
Good luck.
For sharing information in real time among engineers, sales, etc. with Groove Networks. It is a peer-to-peer solution with central administrative control, project-based. You share a project worksace, which users can easily create, specify who can join, and all project documents are automatically kept up to date across all users on the project. Lots of other cool features, too.
If you already have Notes/Domino, you coudl easly just set up a discusson database or document library per project, and allow mobile users to take local replicas of them.
With either solution (Groove/Domino), you wil need that product's server and administrative software. Groove requires each client to have the client software installed; DOmino requires either Notes software, iNotes, or just we browser. (If you use just Web Browser, you can't provide mobile access). There is no special networking setup required for either Domino or Grove.
Another point: it is theoretically posible to set up Domino and Groove systems across sites using teh internet without a VPN. That's becase the products have built-in encryoton facilities that are functional equivalents of a VPN. This is easier to set up using DOmino, but I believe it is also possible using Groove (by having two phantom "bot" users on every project, one per office, available on the internet.)
If you already have Notes/Domino, you coudl easly just set up a discusson database or document library per project, and allow mobile users to take local replicas of them.
With either solution (Groove/Domino), you wil need that product's server and administrative software. Groove requires each client to have the client software installed; DOmino requires either Notes software, iNotes, or just we browser. (If you use just Web Browser, you can't provide mobile access). There is no special networking setup required for either Domino or Grove.
Another point: it is theoretically posible to set up Domino and Groove systems across sites using teh internet without a VPN. That's becase the products have built-in encryoton facilities that are functional equivalents of a VPN. This is easier to set up using DOmino, but I believe it is also possible using Groove (by having two phantom "bot" users on every project, one per office, available on the internet.)
ShineOn,
> Which is what Nterprise Branch office is, as well as iFolder, iPrint, etc.
iFolder isn't exactly Web Services, since it can't be queried and manipulated programmatically via SOAP.
If you don't have anything in place, iFolder is a not-bad, inexpensive solution to file sharing. It basically adds a folder to Windows -- similar to My Network Places / Network Neighborhood. The folder sends the files to be stored on the iFolder server, and they can be retrieved back from teh same folder, or managed via a web browser interface.
If you have Domino, you already have a similar facility available in the Domino File Store.
The key thing to look at though is flexibility in sharing the documents across your team. iFolder and Domino do not offer collaborative updates to a document, unless you add additional products. They have limited facilities for managing files nin the context of a larger "project" framework.
> Which is what Nterprise Branch office is, as well as iFolder, iPrint, etc.
iFolder isn't exactly Web Services, since it can't be queried and manipulated programmatically via SOAP.
If you don't have anything in place, iFolder is a not-bad, inexpensive solution to file sharing. It basically adds a folder to Windows -- similar to My Network Places / Network Neighborhood. The folder sends the files to be stored on the iFolder server, and they can be retrieved back from teh same folder, or managed via a web browser interface.
If you have Domino, you already have a similar facility available in the Domino File Store.
The key thing to look at though is flexibility in sharing the documents across your team. iFolder and Domino do not offer collaborative updates to a document, unless you add additional products. They have limited facilities for managing files nin the context of a larger "project" framework.
qwaletee -
Groove is that collaboration project started as a startup by whatsisname that developed Notes when Lotus was Lotus, right? I guess I'd have to see some case studies of successful implementations along the lines of what JamesBrownIII is looking for. It may well be the optimal solution for his situation. My recommendations are with an eye toward standards-based, open-source friendly solutions that will carry them into the next phase of computing, while getting the job done. That doesn't mean that a proprietary collaborative environment won't work, by any means.
iFolder IS a Web service. SOAP does not define Web services by any stretch of the imagination; SOAP is essentially an extension to XML (which also does not define Web services.) Also, iFolder is not everything, it is just ONE thing. It lets you access your "home base" files through the web, update them, and have it sync back to the files at the master site by only sending the deltas, saving transmission time. It's not meant for collaboration, it's meant for on-the-road access and update of your own documents. There are other pieces of Nterprise services that handle the collaborative functions, including email and secure IM.
I also clearly described that in order to track an order from proposal through delivery, additional programming would have to be done.
There is always more than one way to skin a cat, and I think we both have presented workable options to skin this one. A lot depends on where they want to take it, and whether they have current technology investments that can be leveraged.
Groove is that collaboration project started as a startup by whatsisname that developed Notes when Lotus was Lotus, right? I guess I'd have to see some case studies of successful implementations along the lines of what JamesBrownIII is looking for. It may well be the optimal solution for his situation. My recommendations are with an eye toward standards-based, open-source friendly solutions that will carry them into the next phase of computing, while getting the job done. That doesn't mean that a proprietary collaborative environment won't work, by any means.
iFolder IS a Web service. SOAP does not define Web services by any stretch of the imagination; SOAP is essentially an extension to XML (which also does not define Web services.) Also, iFolder is not everything, it is just ONE thing. It lets you access your "home base" files through the web, update them, and have it sync back to the files at the master site by only sending the deltas, saving transmission time. It's not meant for collaboration, it's meant for on-the-road access and update of your own documents. There are other pieces of Nterprise services that handle the collaborative functions, including email and secure IM.
I also clearly described that in order to track an order from proposal through delivery, additional programming would have to be done.
There is always more than one way to skin a cat, and I think we both have presented workable options to skin this one. A lot depends on where they want to take it, and whether they have current technology investments that can be leveraged.
ASKER
Thanks guys for your imput
Just one thing .. consider say the sales agents were in Australia or japan dealing with customers to get the details for the bike how then could they get into the system with the solutions you have given me. I know Domino would be easy with a client but how would that work.
I think I will split the points and thanks again fellas !!
Just one thing .. consider say the sales agents were in Australia or japan dealing with customers to get the details for the bike how then could they get into the system with the solutions you have given me. I know Domino would be easy with a client but how would that work.
I think I will split the points and thanks again fellas !!
ASKER
Also qwaletee
When you say "If you use just Web Browser, you can't provide mobile access"
what exactly do you mean by that ?
When you say "If you use just Web Browser, you can't provide mobile access"
what exactly do you mean by that ?
ASKER
OK I realise that the 5 sales account executives abroad and even at home could be VERY expensive. Even if we were to equip them with a laptop or what ever the cost of cars and travel is still alot. Say we set up an E-shop where the users could log onto and in effect design their OWN bike for manufacture .. what software, hardware would we need and how could we tie this into the system with either NOTES or NOVELL ????
THanks guys .. nothing is ever simple when your learning !
THanks guys .. nothing is ever simple when your learning !
Wow.
I don't know about Domino and easy in the same sentence. It depends on how well-versed you are with Domino and how good your programmers and analysts are. Once the product is developed, sure, it would be relatively easy from the user's standpoint, but although it is a slick development platform, as with ANY development platform, to have it work well you have to know what you are doing.
As far as I know, using the Novell tools, you CAN provide mobile access through the browser. That's the designed goal - it's done with applets and servlets. I am not aware of any proprietary clients that are needed for Nterprise stuff. Authentication would be through HTTPS, with encryption, to provide security; a temporary certificate may have to be downloaded for the encryption.
It wouldn't matter where they are - just that they can get Web access.
I strongly recommend that you visit the Novell website to learn how Novell is enabling the Web for the enterprise. A lot of the blurbs lately have been about Linux and the Ximian and SuSE acquisitions, but if you get past that to the product and solution offerings and take a look at the case studies, you might be surprised at what Novell has to offer.
As far as an end-user doing their own bike design, that's a bit beyond this question. It can be done, I'm sure, but I think that would definitely be a custom programming effort no matter what back-end or web tools you decide on.
Glad to be of help in adding to the confusion ... hehe...
I don't know about Domino and easy in the same sentence. It depends on how well-versed you are with Domino and how good your programmers and analysts are. Once the product is developed, sure, it would be relatively easy from the user's standpoint, but although it is a slick development platform, as with ANY development platform, to have it work well you have to know what you are doing.
As far as I know, using the Novell tools, you CAN provide mobile access through the browser. That's the designed goal - it's done with applets and servlets. I am not aware of any proprietary clients that are needed for Nterprise stuff. Authentication would be through HTTPS, with encryption, to provide security; a temporary certificate may have to be downloaded for the encryption.
It wouldn't matter where they are - just that they can get Web access.
I strongly recommend that you visit the Novell website to learn how Novell is enabling the Web for the enterprise. A lot of the blurbs lately have been about Linux and the Ximian and SuSE acquisitions, but if you get past that to the product and solution offerings and take a look at the case studies, you might be surprised at what Novell has to offer.
As far as an end-user doing their own bike design, that's a bit beyond this question. It can be done, I'm sure, but I think that would definitely be a custom programming effort no matter what back-end or web tools you decide on.
Glad to be of help in adding to the confusion ... hehe...
I think there are automobile manufacturer sites that allow a customer to design and order their car online, but that is within the strictures of the options made available for a model. I think Saturn provides that functionality on their site.
If you design your site along those lines, where you have a fixed set of options, the concept would work fairly well. It all depends on how much customization you want to provide through your website.
If you design your site along those lines, where you have a fixed set of options, the concept would work fairly well. It all depends on how much customization you want to provide through your website.
ASKER
Im thinking a website front end using XML to suck out the data but what sort of database/server software and hardware solution would you recommend ? Baring in mind the intranet we wish to have also within the sales, manufacturing, warehouse (forget about the 5 sales account executives -- THEY VE BEEN SACKED !!) ;)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
IB, is definitely putting more resource into WebSphere than other dev platforms at the moment -- true. But unles your app is very large, I find...
WebSphere -- or other Java application server systems -- will not give you quick turnaround. .Net gives slightly better turnaround. Domino gives very quick turnaround.
Java developers are expensive. .Net developers as a whole are less expensive, but they are of mixed quality (there are a lot of ".Net" developers who have never really developed anything sophisticated in .Net, while most WebSphere, BEA, or other programmers of Java App servers do have experience with serious applications). Domino developers tend to be cheaper these days, and you can usually get decent quality from anyone with more than a couple of years of experience.
Overall, fora company of your size, I would make my decisions as follows:
1) If you already have a platform -- BEA, Domino, WebSphere, .Net -- use it
2) If you expect the application to become very complex, go with WebSphere or BEA, but expect to pay for it, and don't expect it to happen very quickly
3) For medium complexity, toss-up between Domino and .Net. You can go a little further with .Net, but it will take some more effort getting there.
WebSphere -- or other Java application server systems -- will not give you quick turnaround. .Net gives slightly better turnaround. Domino gives very quick turnaround.
Java developers are expensive. .Net developers as a whole are less expensive, but they are of mixed quality (there are a lot of ".Net" developers who have never really developed anything sophisticated in .Net, while most WebSphere, BEA, or other programmers of Java App servers do have experience with serious applications). Domino developers tend to be cheaper these days, and you can usually get decent quality from anyone with more than a couple of years of experience.
Overall, fora company of your size, I would make my decisions as follows:
1) If you already have a platform -- BEA, Domino, WebSphere, .Net -- use it
2) If you expect the application to become very complex, go with WebSphere or BEA, but expect to pay for it, and don't expect it to happen very quickly
3) For medium complexity, toss-up between Domino and .Net. You can go a little further with .Net, but it will take some more effort getting there.
With .Net, until the Mono project yields results, is a single-platform option, as well. I hate to recommend that anyone tie themselves to a vertical solution. Essentially, most .Net programmers are old VB and VC programmers that don't want to be left in the dust. C#, the foundation language of .Net, is not much more than Microsoft's response to Java.
The complexity of the platform is entirely dependent on how you design your environment. You can have a Domino platform that is complex beyond belief, or a WebSphere environment that is clean and manageable. A lot depends on the quality of your systems analysts and how well they know how to leverage the platform.
Don't assume that any rollout of a Microsoft project will be quick, cheap and easy, as well as robust, secure and resilient, just because Microsoft has all those nifty commercials during sports programs. Not likely, unless you're a big company that Microsoft sends their own engineers and programmers in to make you a poster-child "success story" for next to nothing. I have yet to see a project based on Microsoft technologies come in in-time, on-budget, with all expected features, security and performance. Not to say it isn't possible. It just doesn't seem very likely to me.
Domino is a great tool, and I will not slam it in any way. It is just that it competes with WebSphere/DB2, which is where IBM's future direction appears to be.
As what I assume to be a growing company, you want to have portability and scaleability in whatever you choose, so although there may be more up-front work getting a good, solid solution from a platform like WebSphere/DB2, the long-term benefit of platform portability could well be worth it.
I have gone through so many conversion projects resulting from lack of foresight that whenever I am asked a question about what to choose going forward, I always recommend what I feel to be most likely to be around for a number of years, be scalable to meet potential growth, and be portable to allow you to change hardware platforms without a major, costly conversion process.
Again, these are my opinions; you can place whatever value you want on them, including the price you paid for them... hehe...
The complexity of the platform is entirely dependent on how you design your environment. You can have a Domino platform that is complex beyond belief, or a WebSphere environment that is clean and manageable. A lot depends on the quality of your systems analysts and how well they know how to leverage the platform.
Don't assume that any rollout of a Microsoft project will be quick, cheap and easy, as well as robust, secure and resilient, just because Microsoft has all those nifty commercials during sports programs. Not likely, unless you're a big company that Microsoft sends their own engineers and programmers in to make you a poster-child "success story" for next to nothing. I have yet to see a project based on Microsoft technologies come in in-time, on-budget, with all expected features, security and performance. Not to say it isn't possible. It just doesn't seem very likely to me.
Domino is a great tool, and I will not slam it in any way. It is just that it competes with WebSphere/DB2, which is where IBM's future direction appears to be.
As what I assume to be a growing company, you want to have portability and scaleability in whatever you choose, so although there may be more up-front work getting a good, solid solution from a platform like WebSphere/DB2, the long-term benefit of platform portability could well be worth it.
I have gone through so many conversion projects resulting from lack of foresight that whenever I am asked a question about what to choose going forward, I always recommend what I feel to be most likely to be around for a number of years, be scalable to meet potential growth, and be portable to allow you to change hardware platforms without a major, costly conversion process.
Again, these are my opinions; you can place whatever value you want on them, including the price you paid for them... hehe...
ShineOn,
> The complexity of the platform is entirely dependent on how you design your
> environment. You can have a Domino platform that is complex beyond belief,
> or a WebSphere environment that is clean and manageable
The complexity I refer to is complexity of the application, not the environment. If you have what I wll nebulously define as a "very complex" aplication, you may find Domino start to show its holes, and you will more than likely come across the "new platform" deficiencies of either .Net itself or its relatively inexperienced coders. Java, being more mature, than .Net and more comprehensive in its progarmming support, can typically handle the most complex applications better. However, the platform itself is typically results in more complex code.
Some key differences among the platforms as development environments:
Domino: Self contained database. Flexible data definitions (mean less time building data structures, but easier to get into trouble with too loose structures or inability to create structure). Form-driven and document-collection-driven
Java: Very flexible platfomr. But, few high-level services built in. You must typically build all of it yourself, or know lots and lots of sources of code to adopt. Has no underlying adtabase, so you must separately purchase a database to work alongside it. Typicaly databases are Oracle, SQL Server, Sybase, MySQL, or DB2. Platform was designed when application serve concepts were immature, so some code and process management is difficult. Development environment is not well-integrated with application server, making rollout and debugging difficult sometimes. Typical deveopment cycle requires strong database and application architectural planning.
.Net: Recently developed, so more conceptually complete than Java app dev. Recently developed, so less complete in implemetation than Java app dev (lack of existing libraries and frameworks, for example). Recently developed, so few strong experts. Requires separate database, typically SQL Server. Nicely integrated IDE, server deployment, and debuging. Otherwise simialr to Java app dev (including requirement of string database and application architectural planning, which, as I said, is still in short supply).
You can see how these overviews dovetail with my earlier comment, once you recognize that I am talking about application coplexity, not administraive complexity, or maintnance complexity. Very complex code is best suited to Java because of the maturity of the platform and its developers, and its completeness. However, it is a pain to develop for, debug, and roll out to. Domino is the easiest to develop and roll out for, but it has some built-in limitations, and therefore, is a good choice if the application itself is not complex enough to cuase issues for the platform. .Net is easier to manage/deploy, and has similar capabilities to Java, but because of its imaturity, should not be used for the most complex applications, making it a good alternative to Domino of you don't have Domino and the application is somewhat complex -- but not complex enough to make the immaturity an issue.
> The complexity of the platform is entirely dependent on how you design your
> environment. You can have a Domino platform that is complex beyond belief,
> or a WebSphere environment that is clean and manageable
The complexity I refer to is complexity of the application, not the environment. If you have what I wll nebulously define as a "very complex" aplication, you may find Domino start to show its holes, and you will more than likely come across the "new platform" deficiencies of either .Net itself or its relatively inexperienced coders. Java, being more mature, than .Net and more comprehensive in its progarmming support, can typically handle the most complex applications better. However, the platform itself is typically results in more complex code.
Some key differences among the platforms as development environments:
Domino: Self contained database. Flexible data definitions (mean less time building data structures, but easier to get into trouble with too loose structures or inability to create structure). Form-driven and document-collection-driven
Java: Very flexible platfomr. But, few high-level services built in. You must typically build all of it yourself, or know lots and lots of sources of code to adopt. Has no underlying adtabase, so you must separately purchase a database to work alongside it. Typicaly databases are Oracle, SQL Server, Sybase, MySQL, or DB2. Platform was designed when application serve concepts were immature, so some code and process management is difficult. Development environment is not well-integrated with application server, making rollout and debugging difficult sometimes. Typical deveopment cycle requires strong database and application architectural planning.
.Net: Recently developed, so more conceptually complete than Java app dev. Recently developed, so less complete in implemetation than Java app dev (lack of existing libraries and frameworks, for example). Recently developed, so few strong experts. Requires separate database, typically SQL Server. Nicely integrated IDE, server deployment, and debuging. Otherwise simialr to Java app dev (including requirement of string database and application architectural planning, which, as I said, is still in short supply).
You can see how these overviews dovetail with my earlier comment, once you recognize that I am talking about application coplexity, not administraive complexity, or maintnance complexity. Very complex code is best suited to Java because of the maturity of the platform and its developers, and its completeness. However, it is a pain to develop for, debug, and roll out to. Domino is the easiest to develop and roll out for, but it has some built-in limitations, and therefore, is a good choice if the application itself is not complex enough to cuase issues for the platform. .Net is easier to manage/deploy, and has similar capabilities to Java, but because of its imaturity, should not be used for the most complex applications, making it a good alternative to Domino of you don't have Domino and the application is somewhat complex -- but not complex enough to make the immaturity an issue.
qwaletee -
I think we agree in principle on the usefulness and ease-of-use of the relative platforms. I think where we part ways is in the expandability and portability of the platforms.
You might do very well creating a "dot net" based application, but you WILL be tied to the Windows platform, with all of its inherent deficiencies.
You are not entirely tied to a Windows platform with Domino. I think IBM still supports Domino on at least a couple of their other platforms - at least they used to support it on AIX and OS/400...
You are not tied to a Windows platform with WebSphere/OS2. Last I heard, WebSphere is the leading AppServer platform.
That's where I'm coming from. Not just initial ease-of-use or initial cost-to-deploy but long-term total cost of ownership, scalability and platform-independence.
I think we agree in principle on the usefulness and ease-of-use of the relative platforms. I think where we part ways is in the expandability and portability of the platforms.
You might do very well creating a "dot net" based application, but you WILL be tied to the Windows platform, with all of its inherent deficiencies.
You are not entirely tied to a Windows platform with Domino. I think IBM still supports Domino on at least a couple of their other platforms - at least they used to support it on AIX and OS/400...
You are not tied to a Windows platform with WebSphere/OS2. Last I heard, WebSphere is the leading AppServer platform.
That's where I'm coming from. Not just initial ease-of-use or initial cost-to-deploy but long-term total cost of ownership, scalability and platform-independence.
Oops, I meant WebSphere/DB2, not WebSphere/OS2...
Anyway, when you are in the rare position to essentially start from scratch, and money (although always important) is not the deciding factor, it is best in my opinion to go with the option that will grow with your company, rather than to get a potential throw-away solution. Conversion costs are much higher than the cost to buy and configure the new software and hardware; you also have the cost of productivity decline during the transition and ramp-up, training costs, the cost of the inevitable errors during the conversion process, and more.
If there is considerable doubt as to the viability of the company, go as cheap as possible to save the upfront costs, because if the company takes off, it should be able to afford the conversion/upgrade costs. But if the company is on solid footing and is fully expected to grow, then doing it right the first time makes SO much more sense.
A good rule of thumb with any IT project is: "Good. Fast. Cheap. Pick two." If you go with fast deployment and cheap cost, don't expect it to be good. If you want it to be good, but cheap, don't expect it to be up-and-running tomorrow. If you want it good and you want it fast, expect to have to open your wallet. I have yet to encounter any environment (hardware, software, development) that contradicts that rule of thumb.
If there is considerable doubt as to the viability of the company, go as cheap as possible to save the upfront costs, because if the company takes off, it should be able to afford the conversion/upgrade costs. But if the company is on solid footing and is fully expected to grow, then doing it right the first time makes SO much more sense.
A good rule of thumb with any IT project is: "Good. Fast. Cheap. Pick two." If you go with fast deployment and cheap cost, don't expect it to be good. If you want it to be good, but cheap, don't expect it to be up-and-running tomorrow. If you want it good and you want it fast, expect to have to open your wallet. I have yet to encounter any environment (hardware, software, development) that contradicts that rule of thumb.
An historical example:
8-10 years ago all the rage was object-oriented programming(OOP). RAD (Rapid Application Development) was based on the concept of OOP. The coolest RAD tool around was Powerbuilder. Once you defined your business rules and established your basic objects, hot damn - you could throw together a cool Windows app in no time.
Problem was, it was a resource hog, plus you had to pay a chunk for the software and had to spend money on training your programming staff how to use it. Even then, you weren't guaranteed a good product if you didn't have someone to properly analyze your business processes in order to define the business rules on which the objects should be based. Over time, it got more efficient as far as resources, but how many years has it been since you've heard anyone talk about Powerbuilder? What happened is Microsoft practically gave away Visual Basic for free, and optimized their systems to run VB apps, so even though PowerBuilder was a superior development tool and application concept, VB won the day.
Nowadays, however, VB is starting to gather some tarnish. More developers are using C++ and open-source tools like Java, PHP, PERL, etc. because they are portable to so many OS platforms, and VB is getting a bad rep because it is tied to the Windows platform as well as having the inefficiencies and DLL-hell problems that are supposed to be cured with C#.
C# can be a great app-dev platform. Who knows at this point. It is a baby, still "wet behind the ears." So much of it is an obvious reengineering of Java, it is sad. People that are used to developing in C, a mature high-level language, have no problems transitioning to either Java or C#, according to the reports I've seen. The big thing with C# is that it protects memory so much better than C did, since C was developed WAY before 32-bit memory addressing, much less the 64-bit that is on the horizon, and is better at protecting resources - after the fashion of Java. The big drawback of C# is that it currently is only available on Windows. C runs on dang-near anything. Same concept was applied to Java, without the need to re-code for a platform - the concept of "write once, run anywhere." Although that ideal hasn't quite been met, it is so much closer to a universal, platform-independent language than is C#, the distinction is clear. Any major push for C# has to be tainted by Microsot's hand behind the scenes, as nobody else has C#. C# IS "dot-net."
They have presented it as a "standard" and the Mono project is addressing portability and cross-platform compatibility between Windows and Linux/*nix, but what is your wager that once Mono's first release comes out, Microsoft will make a change to keep it "Windows-optimized?"
There is no such isse with Java, or with the open-source programming and scripting tools.
8-10 years ago all the rage was object-oriented programming(OOP). RAD (Rapid Application Development) was based on the concept of OOP. The coolest RAD tool around was Powerbuilder. Once you defined your business rules and established your basic objects, hot damn - you could throw together a cool Windows app in no time.
Problem was, it was a resource hog, plus you had to pay a chunk for the software and had to spend money on training your programming staff how to use it. Even then, you weren't guaranteed a good product if you didn't have someone to properly analyze your business processes in order to define the business rules on which the objects should be based. Over time, it got more efficient as far as resources, but how many years has it been since you've heard anyone talk about Powerbuilder? What happened is Microsoft practically gave away Visual Basic for free, and optimized their systems to run VB apps, so even though PowerBuilder was a superior development tool and application concept, VB won the day.
Nowadays, however, VB is starting to gather some tarnish. More developers are using C++ and open-source tools like Java, PHP, PERL, etc. because they are portable to so many OS platforms, and VB is getting a bad rep because it is tied to the Windows platform as well as having the inefficiencies and DLL-hell problems that are supposed to be cured with C#.
C# can be a great app-dev platform. Who knows at this point. It is a baby, still "wet behind the ears." So much of it is an obvious reengineering of Java, it is sad. People that are used to developing in C, a mature high-level language, have no problems transitioning to either Java or C#, according to the reports I've seen. The big thing with C# is that it protects memory so much better than C did, since C was developed WAY before 32-bit memory addressing, much less the 64-bit that is on the horizon, and is better at protecting resources - after the fashion of Java. The big drawback of C# is that it currently is only available on Windows. C runs on dang-near anything. Same concept was applied to Java, without the need to re-code for a platform - the concept of "write once, run anywhere." Although that ideal hasn't quite been met, it is so much closer to a universal, platform-independent language than is C#, the distinction is clear. Any major push for C# has to be tainted by Microsot's hand behind the scenes, as nobody else has C#. C# IS "dot-net."
They have presented it as a "standard" and the Mono project is addressing portability and cross-platform compatibility between Windows and Linux/*nix, but what is your wager that once Mono's first release comes out, Microsoft will make a change to keep it "Windows-optimized?"
There is no such isse with Java, or with the open-source programming and scripting tools.
ShineOn,
> You are not entirely tied to a Windows platform with Domino. I think IBM
> still supports Domino on at least a couple of their other platforms - at least
> they used to support it on AIX and OS/400...
I don't disagree that .Net is tied to Windows, and tha it COULD be a bad thing. However, for all practical purposes, if you are a small Windows shop, you wil probably stay that way.
Domino can live on Windows, Solaris, AIX, Linux, iSeries (AS/400), or zOS (s/390). Hs odd issues on the latter two, BTW. Not sure if it still has HP-UX or OS/2, I think it does both.
WebSphere and WebLogic run neck and neck. WebLogic also supports a variety of Unix flavors.
Cost to deploy? Windows wins. L/T TCO -- Windows wins if you don't need to scale. Scalability? If it matters, Windows loses. Platform? Well, other than scalability and security, I see no reason to care. I thik that's where we differ. I'm willing to give WIndows some due.
Good. Fast. Cheap. I agree -- but I like to break down Good into "Robust" and "Complete", and I add "Sanity." As in yorus.
Robust
Complete
Quick
Cheap
Pick any two and save your sanity. Pick three, and hope to tell about it. Pick four, and check your life insurance's suicide clause.
> You are not entirely tied to a Windows platform with Domino. I think IBM
> still supports Domino on at least a couple of their other platforms - at least
> they used to support it on AIX and OS/400...
I don't disagree that .Net is tied to Windows, and tha it COULD be a bad thing. However, for all practical purposes, if you are a small Windows shop, you wil probably stay that way.
Domino can live on Windows, Solaris, AIX, Linux, iSeries (AS/400), or zOS (s/390). Hs odd issues on the latter two, BTW. Not sure if it still has HP-UX or OS/2, I think it does both.
WebSphere and WebLogic run neck and neck. WebLogic also supports a variety of Unix flavors.
Cost to deploy? Windows wins. L/T TCO -- Windows wins if you don't need to scale. Scalability? If it matters, Windows loses. Platform? Well, other than scalability and security, I see no reason to care. I thik that's where we differ. I'm willing to give WIndows some due.
Good. Fast. Cheap. I agree -- but I like to break down Good into "Robust" and "Complete", and I add "Sanity." As in yorus.
Robust
Complete
Quick
Cheap
Pick any two and save your sanity. Pick three, and hope to tell about it. Pick four, and check your life insurance's suicide clause.
"Cost to deploy? Windows wins."
Disagree.
Deployment costs include a lot more than how much the server OS costs and how much the hardware costs. It includes the cost of the desktop/user environment (hardware/software) the cost of the development tools, the cost of analysis and development, the cost of user training, the cost of retooling and/or refitting your operation as may be needed to fit the restricitons of your choice, the cost of customer relations during your changeover... etc. etc.
If you get a solid, workable solution that happens to have a higher hardware cost and similar software costs (the software costs are debatable with Windows/.Net) the remaining costs must factor in. They don't in Microsoft's sales pitch. The ongoing support costs also do not factor into the Microsoft sales pitch.
If you are a small Windows shop, that's probably because you didn't know better. If you are a large Windows shop, you are likely feeling the pain.
Long-term TCO, there is no way Windows wins, even if you don't consider growth as a concern. It takes more hardware and more technical resources per user to support an effective Windows environment than just about any other.
I will give Windows the "due" that it can act as a decent client OS if controlled, and can be useful as a limited-function application server within your environment, but it is not wise to put all your eggs in the Microsoft basket unless you want to make omelets with drippings off the basket.
Good, fast, cheap stays good, fast, cheap. Your breakdown doesn't apply to all scenarios, but the original does. Name one where it doesn't, and you get the gold star for the day.
Disagree.
Deployment costs include a lot more than how much the server OS costs and how much the hardware costs. It includes the cost of the desktop/user environment (hardware/software) the cost of the development tools, the cost of analysis and development, the cost of user training, the cost of retooling and/or refitting your operation as may be needed to fit the restricitons of your choice, the cost of customer relations during your changeover... etc. etc.
If you get a solid, workable solution that happens to have a higher hardware cost and similar software costs (the software costs are debatable with Windows/.Net) the remaining costs must factor in. They don't in Microsoft's sales pitch. The ongoing support costs also do not factor into the Microsoft sales pitch.
If you are a small Windows shop, that's probably because you didn't know better. If you are a large Windows shop, you are likely feeling the pain.
Long-term TCO, there is no way Windows wins, even if you don't consider growth as a concern. It takes more hardware and more technical resources per user to support an effective Windows environment than just about any other.
I will give Windows the "due" that it can act as a decent client OS if controlled, and can be useful as a limited-function application server within your environment, but it is not wise to put all your eggs in the Microsoft basket unless you want to make omelets with drippings off the basket.
Good, fast, cheap stays good, fast, cheap. Your breakdown doesn't apply to all scenarios, but the original does. Name one where it doesn't, and you get the gold star for the day.
ShineOn,
> Good, fast, cheap stays good, fast, cheap. Your breakdown doesn't apply to
> all scenarios, but the original does. Name one where it doesn't, and you get
> the gold star for the day.
Not sure what you meant by that last bit.
Honestly, I agree with you on most points, but I think you do have an anti-Windows bias. I simply like to look at things agnostically. If you have very limited IT resources, in a small shop, Windows is usually a best bet. Why? The desktop support overlaps the infrastructure support, leveraging the skill base. Plus, for a non-technical person, Windows "training by doing" is definitely easier than any flavor of *nix (including Linux, why does anybody bother to differentiate anymore?). I support a number of businesses that got by with the owner tinkering with a handful of Windows PCs until he grew large enough to need at least part time IT. I don't know anyone non-technical who has set up a Linux system without a lot of handholding.
So, most of your big shpiel in the first paragraph seems to me, in teh final analysis, to FAVOR Windows in a small installation. Hardware? Only Linux truly needs less. Dev tools? Almost every dev tool is available at equal or lowe cost for Windows than wit other environments, unless you plan on using gcc for everything. Analysis? Shoudl be more or less the same across environments, not a COMPARATIVE cost fator. Actual development? That has to come out of analysis. In the example we are using here, within its limits, Domino is by far the fastest dev environment I've used -- and it runs on Windows (server can run on anything). Visual Studio/VS.Net is also a very clear leader. User training? Only relevant on the desktp, which WILL be Windows; if browser-based, the deesktop is irrelevant, but Windows does not gain or lose, it isn't a COMPARATIVE cost factor. Retooling? That depends on what you had before. If WIndows, then Windows has lower retoooling costs -- usually. If something else, then Windows will have higher retooling costs. Customer relations? Can't estimate that, depends on analysis and environment.
So, if the limits of Windows as infrastructure are more than sufficient for your forseeable business future, I say fine. Do teh analysis, but you wll probably end up with Redmond. If not, run-don't-walk to something that will meet your needs.
I also realize as I'm typing this that we're failing to sufficiently break apart two concepts: Windows as a desktop/server OS, and Microsoft business infrastructure applications and application tools (IIS, .Net Exchange, MTS, etc.). If you use MS tools, you must use Windows (except for the old Chil!soft ASP kludge). If you choose something else, then yo have to decide what HOSTING platform to use, which may or may not be Windows.
I still say my earlier analysis holds true. You have to do a basic analysis to size the application and look at your existing environment. Then my guidelines will lead you to a good choice of platform.
> Good, fast, cheap stays good, fast, cheap. Your breakdown doesn't apply to
> all scenarios, but the original does. Name one where it doesn't, and you get
> the gold star for the day.
Not sure what you meant by that last bit.
Honestly, I agree with you on most points, but I think you do have an anti-Windows bias. I simply like to look at things agnostically. If you have very limited IT resources, in a small shop, Windows is usually a best bet. Why? The desktop support overlaps the infrastructure support, leveraging the skill base. Plus, for a non-technical person, Windows "training by doing" is definitely easier than any flavor of *nix (including Linux, why does anybody bother to differentiate anymore?). I support a number of businesses that got by with the owner tinkering with a handful of Windows PCs until he grew large enough to need at least part time IT. I don't know anyone non-technical who has set up a Linux system without a lot of handholding.
So, most of your big shpiel in the first paragraph seems to me, in teh final analysis, to FAVOR Windows in a small installation. Hardware? Only Linux truly needs less. Dev tools? Almost every dev tool is available at equal or lowe cost for Windows than wit other environments, unless you plan on using gcc for everything. Analysis? Shoudl be more or less the same across environments, not a COMPARATIVE cost fator. Actual development? That has to come out of analysis. In the example we are using here, within its limits, Domino is by far the fastest dev environment I've used -- and it runs on Windows (server can run on anything). Visual Studio/VS.Net is also a very clear leader. User training? Only relevant on the desktp, which WILL be Windows; if browser-based, the deesktop is irrelevant, but Windows does not gain or lose, it isn't a COMPARATIVE cost factor. Retooling? That depends on what you had before. If WIndows, then Windows has lower retoooling costs -- usually. If something else, then Windows will have higher retooling costs. Customer relations? Can't estimate that, depends on analysis and environment.
So, if the limits of Windows as infrastructure are more than sufficient for your forseeable business future, I say fine. Do teh analysis, but you wll probably end up with Redmond. If not, run-don't-walk to something that will meet your needs.
I also realize as I'm typing this that we're failing to sufficiently break apart two concepts: Windows as a desktop/server OS, and Microsoft business infrastructure applications and application tools (IIS, .Net Exchange, MTS, etc.). If you use MS tools, you must use Windows (except for the old Chil!soft ASP kludge). If you choose something else, then yo have to decide what HOSTING platform to use, which may or may not be Windows.
I still say my earlier analysis holds true. You have to do a basic analysis to size the application and look at your existing environment. Then my guidelines will lead you to a good choice of platform.