Brajeshwar believes in simplicity; pushes the envelop and envisions the betterment of usable and practical solutions.
Published
13 Comments
We've used the term Enterprise RIA quite freely, to describe Rich Internet Applications that are tightly coupled to enterprise middleware, typically J2EE or .NET.
These applications are "multiple use-case" applications - the number of features that a user can do with the application typically being measured as 20+ (and in some cases, much much mor) rather than being able to perform a single task (such as fetching weather for a given postcode) or perhaps 2 or 3 tasks.
For an enterprise RIA, we have also found irrespective of the complexity, richness and interactivity of the UI, it is typically the tip of the development iceberg, often comprising no more than 25-30% of the actual development effort, for a complete end-to-end bespoke development.
The above figures are purely arbitrary built on the typical "enterprise RIAs" that we've been involved in developing, and will obviously vary depending on the complexity of the UI and the amount of existing middleware in place.
Does that help ?
We've used the term Enterprise RIA quite freely, to describe Rich Internet Applications that are tightly coupled to enterprise middleware, typically J2EE or .NET.
These applications are "multiple use-case" applications - the number of features that a user can do with the application typically being measured as 20+ (and in some cases, much much mor) rather than being able to perform a single task (such as fetching weather for a given postcode) or perhaps 2 or 3 tasks.
For an enterprise RIA, we have also found irrespective of the complexity, richness and interactivity of the UI, it is typically the tip of the development iceberg, often comprising no more than 25-30% of the actual development effort, for a complete end-to-end bespoke development.
The above figures are purely arbitrary built on the typical "enterprise RIAs" that we've been involved in developing, and will obviously vary depending on the complexity of the UI and the amount of existing middleware in place.
Does that help ?
I think "Enterprise" infers two things about an application:
1) The scale of the application 2) The size of the company implementing the application
I also think "Enterprise" applications tend to have more of a B-to-B than a B-to-C focus.
In the end, it's really just a buzz-word. Using it tends to raise the "importance" of the application, as well as the development fee...
Interesting question. I think "enterprise" is a marketing term, and doesn't mean anything outside the marketing department (I mean no disrepect to Steven's previous post). Here are the best two examples I can think of:
My current app is a bond reporting instrument built in Flash. It gives the client's subscribers real time updates of bond data as they are entered into the database, and high availabilty is one of the core app requirements. You don't even get in the door with this company unless you have at least 250K to invest. And yet I haven't heard a SINGLE person use the word "enterprise" in relation to this app or any other app built for the company.
Compare that to a guy who asked me to submit a bid for a different type of Flash reporting app. He wanted to make sure it was an "enterprise application," and then he told me his budget was a couple thousand dollars.
Interesting question. I think "enterprise" is a marketing term, and doesn't mean anything outside the marketing department (I mean no disrepect to Steven's previous post). Here are the best two examples I can think of:
My current app is a bond reporting instrument built in Flash. It gives the client's subscribers real time updates of bond data as they are entered into the database, and high availabilty is one of the core app requirements. You don't even get in the door with this company unless you have at least 250K to invest. And yet I haven't heard a SINGLE person use the word "enterprise" in relation to this app or any other app built for the company.
Compare that to a guy who asked me to submit a bid for a different type of Flash reporting app. He wanted to make sure it was an "enterprise application," and then he told me his budget was a couple thousand dollars.
I definitely agree that it's "marketing", but it's also differentiation ... the "few thousand dollars guy" you describe is exactly the reason that we try to differentiate what we actually mean by Rich Internet Application.
By way of example; our consultancy practice agile development - we've done by the book XP as a team for 4 or 5 years, but all of a sudden, every java development house on the block "is doing agile development" because they wrote a unit-test once. They make changes to their code and they're refactoring. They capture requirements as stories, and now they're doing a planning game. And it pollutes the line between agile development and ad hoc development. :)
Now...we're building Rich Internet Applications, and everyone who pulled dynamic data into their Flash movie once, has been "building Rich Internet Applications for years". It is just a name, I absolutely agree - but when selling, then marketing is important. When we talk about Enterprise RIAs with clients, it gives them a comfort that it's a solution where security, performance, stability and maintainability matter, where development practices must be adhereed to, where development workflows need not be changed. In the words of one company we work with, they were worried from speaking to some people, that RIA was just "Flash on Flash".
I'm happy just building RIAs. But sometimes I have to sell them as Enterprise RIAs first :)
Marc,
I definitely agree that it's "marketing", but it's also differentiation ... the "few thousand dollars guy" you describe is exactly the reason that we try to differentiate what we actually mean by Rich Internet Application.
By way of example; our consultancy practice agile development - we've done by the book XP as a team for 4 or 5 years, but all of a sudden, every java development house on the block "is doing agile development" because they wrote a unit-test once. They make changes to their code and they're refactoring. They capture requirements as stories, and now they're doing a planning game. And it pollutes the line between agile development and ad hoc development. :)
Now...we're building Rich Internet Applications, and everyone who pulled dynamic data into their Flash movie once, has been "building Rich Internet Applications for years". It is just a name, I absolutely agree - but when selling, then marketing is important. When we talk about Enterprise RIAs with clients, it gives them a comfort that it's a solution where security, performance, stability and maintainability matter, where development practices must be adhereed to, where development workflows need not be changed. In the words of one company we work with, they were worried from speaking to some people, that RIA was just "Flash on Flash".
I'm happy just building RIAs. But sometimes I have to sell them as Enterprise RIAs first :)
I think "Enterprise" infers two things about an application:
1) The scale of the application 2) The size of the company implementing the application
I also think "Enterprise" applications tend to have more of a B-to-B than a B-to-C focus.
In the end, it's really just a buzz-word. Using it tends to raise the "importance" of the application, as well as the development fee...
Hello,
I think Marc and Steven are both right...it is a "marketing" designation but as Steven points out, it can be a meaningful one to differentiate in the market.
As we have approached developing Flex at Macromedia, we have thought a lot about the continuum of RIAs and while there are no clear lines, two extremes look like this:
a) Typically *not* described as an "enterprise" app: 2 tier, 1-3 person dev team, boutique application that may be very high impact but is likely not to need to be extended or maintained over multiple years, short dev cycle (less than 6 months), non-mission critical. In my experience, project budgets tend to be in the tens of thousands of dollars to the hundreds of thousands of dollars.
b) Often described as "enterprise": n-tier, 5-50 person team, application needs to be extended and maintained over several to many years , 6-18 month development cycles, use of design patterns such as MVC, tight integration with middleware, mission critical. In my experience project budgets tend to be in the few hundred thousand dollars to the many millions of dollars.
The above is very rough and it is impossible to perfectly segment -- not all apps that may be described as "enterprise" have those characteristics of course and there are many characteristics I haven't mentioned here. But at a high level there are very large differences between applications in the first and second categories in terms of skills typically involved, budgets, timetables, technologies, and processes.
From my view at Macromedia, Flex can be used for many many things, but its sweet spot is "enterprise RIA"; Flash Professional can be used for many many things, but its sweet spot is "RIA" and Interactive Content but usually not with the "enterprise" label. To be clear, there are many many exceptions--this isn't neatly divided into two worlds.
-David macromedia
Hello,
I think Marc and Steven are both right...it is a "marketing" designation but as Steven points out, it can be a meaningful one to differentiate in the market.
As we have approached developing Flex at Macromedia, we have thought a lot about the continuum of RIAs and while there are no clear lines, two extremes look like this:
a) Typically *not* described as an "enterprise" app: 2 tier, 1-3 person dev team, boutique application that may be very high impact but is likely not to need to be extended or maintained over multiple years, short dev cycle (less than 6 months), non-mission critical. In my experience, project budgets tend to be in the tens of thousands of dollars to the hundreds of thousands of dollars.
b) Often described as "enterprise": n-tier, 5-50 person team, application needs to be extended and maintained over several to many years , 6-18 month development cycles, use of design patterns such as MVC, tight integration with middleware, mission critical. In my experience project budgets tend to be in the few hundred thousand dollars to the many millions of dollars.
The above is very rough and it is impossible to perfectly segment -- not all apps that may be described as "enterprise" have those characteristics of course and there are many characteristics I haven't mentioned here. But at a high level there are very large differences between applications in the first and second categories in terms of skills typically involved, budgets, timetables, technologies, and processes.
From my view at Macromedia, Flex can be used for many many things, but its sweet spot is "enterprise RIA"; Flash Professional can be used for many many things, but its sweet spot is "RIA" and Interactive Content but usually not with the "enterprise" label. To be clear, there are many many exceptions--this isn't neatly divided into two worlds.
-David macromedia
There are some nice posts on the serverside.com discussing and comparing various solutions for enteprise rich internet apps:
We've used the term Enterprise RIA quite freely, to describe Rich Internet Applications that are tightly coupled to enterprise middleware, typically J2EE or .NET.
These applications are "multiple use-case" applications - the number of features that a user can do with the application typically being measured as 20+ (and in some cases, much much mor) rather than being able to perform a single task (such as fetching weather for a given postcode) or perhaps 2 or 3 tasks.
For an enterprise RIA, we have also found irrespective of the complexity, richness and interactivity of the UI, it is typically the tip of the development iceberg, often comprising no more than 25-30% of the actual development effort, for a complete end-to-end bespoke development.
The above figures are purely arbitrary built on the typical "enterprise RIAs" that we've been involved in developing, and will obviously vary depending on the complexity of the UI and the amount of existing middleware in place.
Does that help ?
We've used the term Enterprise RIA quite freely, to describe Rich Internet Applications that are tightly coupled to enterprise middleware, typically J2EE or .NET.
These applications are "multiple use-case" applications - the number of features that a user can do with the application typically being measured as 20+ (and in some cases, much much mor) rather than being able to perform a single task (such as fetching weather for a given postcode) or perhaps 2 or 3 tasks.
For an enterprise RIA, we have also found irrespective of the complexity, richness and interactivity of the UI, it is typically the tip of the development iceberg, often comprising no more than 25-30% of the actual development effort, for a complete end-to-end bespoke development.
The above figures are purely arbitrary built on the typical "enterprise RIAs" that we've been involved in developing, and will obviously vary depending on the complexity of the UI and the amount of existing middleware in place.
Does that help ?
I think "Enterprise" infers two things about an application:
1) The scale of the application
2) The size of the company implementing the application
I also think "Enterprise" applications tend to have more of a B-to-B than a B-to-C focus.
In the end, it's really just a buzz-word. Using it tends to raise the "importance" of the application, as well as the development fee...
Interesting question. I think "enterprise" is a marketing term, and doesn't mean anything outside the marketing department (I mean no disrepect to Steven's previous post). Here are the best two examples I can think of:
My current app is a bond reporting instrument built in Flash. It gives the client's subscribers real time updates of bond data as they are entered into the database, and high availabilty is one of the core app requirements. You don't even get in the door with this company unless you have at least 250K to invest. And yet I haven't heard a SINGLE person use the word "enterprise" in relation to this app or any other app built for the company.
Compare that to a guy who asked me to submit a bid for a different type of Flash reporting app. He wanted to make sure it was an "enterprise application," and then he told me his budget was a couple thousand dollars.
"Enterprise" = marketing. Nothing more, nothing less.
Interesting question. I think "enterprise" is a marketing term, and doesn't mean anything outside the marketing department (I mean no disrepect to Steven's previous post). Here are the best two examples I can think of:
My current app is a bond reporting instrument built in Flash. It gives the client's subscribers real time updates of bond data as they are entered into the database, and high availabilty is one of the core app requirements. You don't even get in the door with this company unless you have at least 250K to invest. And yet I haven't heard a SINGLE person use the word "enterprise" in relation to this app or any other app built for the company.
Compare that to a guy who asked me to submit a bid for a different type of Flash reporting app. He wanted to make sure it was an "enterprise application," and then he told me his budget was a couple thousand dollars.
"Enterprise" = marketing. Nothing more, nothing less.
Marc,
I definitely agree that it's "marketing", but it's also differentiation ... the "few thousand dollars guy" you describe is exactly the reason that we try to differentiate what we actually mean by Rich Internet Application.
By way of example; our consultancy practice agile development - we've done by the book XP as a team for 4 or 5 years, but all of a sudden, every java development house on the block "is doing agile development" because they wrote a unit-test once. They make changes to their code and they're refactoring. They capture requirements as stories, and now they're doing a planning game. And it pollutes the line between agile development and ad hoc development. :)
Now...we're building Rich Internet Applications, and everyone who pulled dynamic data into their Flash movie once, has been "building Rich Internet Applications for years". It is just a name, I absolutely agree - but when selling, then marketing is important. When we talk about Enterprise RIAs with clients, it gives them a comfort that it's a solution where security, performance, stability and maintainability matter, where development practices must be adhereed to, where development workflows need not be changed. In the words of one company we work with, they were worried from speaking to some people, that RIA was just "Flash on Flash".
I'm happy just building RIAs. But sometimes I have to sell them as Enterprise RIAs first :)
Marc,
I definitely agree that it's "marketing", but it's also differentiation ... the "few thousand dollars guy" you describe is exactly the reason that we try to differentiate what we actually mean by Rich Internet Application.
By way of example; our consultancy practice agile development - we've done by the book XP as a team for 4 or 5 years, but all of a sudden, every java development house on the block "is doing agile development" because they wrote a unit-test once. They make changes to their code and they're refactoring. They capture requirements as stories, and now they're doing a planning game. And it pollutes the line between agile development and ad hoc development. :)
Now...we're building Rich Internet Applications, and everyone who pulled dynamic data into their Flash movie once, has been "building Rich Internet Applications for years". It is just a name, I absolutely agree - but when selling, then marketing is important. When we talk about Enterprise RIAs with clients, it gives them a comfort that it's a solution where security, performance, stability and maintainability matter, where development practices must be adhereed to, where development workflows need not be changed. In the words of one company we work with, they were worried from speaking to some people, that RIA was just "Flash on Flash".
I'm happy just building RIAs. But sometimes I have to sell them as Enterprise RIAs first :)
I think "Enterprise" infers two things about an application:
1) The scale of the application
2) The size of the company implementing the application
I also think "Enterprise" applications tend to have more of a B-to-B than a B-to-C focus.
In the end, it's really just a buzz-word. Using it tends to raise the "importance" of the application, as well as the development fee...
Hello,
I think Marc and Steven are both right...it is a "marketing" designation but as Steven points out, it can be a meaningful one to differentiate in the market.
As we have approached developing Flex at Macromedia, we have thought a lot about the continuum of RIAs and while there are no clear lines, two extremes look like this:
a) Typically *not* described as an "enterprise" app:
2 tier, 1-3 person dev team, boutique application that may be very high impact but is likely not to need to be extended or maintained over multiple years, short dev cycle (less than 6 months), non-mission critical. In my experience, project budgets tend to be in the tens of thousands of dollars to the hundreds of thousands of dollars.
b) Often described as "enterprise":
n-tier, 5-50 person team, application needs to be extended and maintained over several to many years , 6-18 month development cycles, use of design patterns such as MVC, tight integration with middleware, mission critical. In my experience project budgets tend to be in the few hundred thousand dollars to the many millions of dollars.
The above is very rough and it is impossible to perfectly segment -- not all apps that may be described as "enterprise" have those characteristics of course and there are many characteristics I haven't mentioned here. But at a high level there are very large differences between applications in the first and second categories in terms of skills typically involved, budgets, timetables, technologies, and processes.
From my view at Macromedia, Flex can be used for many many things, but its sweet spot is "enterprise RIA"; Flash Professional can be used for many many things, but its sweet spot is "RIA" and Interactive Content but usually not with the "enterprise" label. To be clear, there are many many exceptions--this isn't neatly divided into two worlds.
-David
macromedia
Hello,
I think Marc and Steven are both right...it is a "marketing" designation but as Steven points out, it can be a meaningful one to differentiate in the market.
As we have approached developing Flex at Macromedia, we have thought a lot about the continuum of RIAs and while there are no clear lines, two extremes look like this:
a) Typically *not* described as an "enterprise" app:
2 tier, 1-3 person dev team, boutique application that may be very high impact but is likely not to need to be extended or maintained over multiple years, short dev cycle (less than 6 months), non-mission critical. In my experience, project budgets tend to be in the tens of thousands of dollars to the hundreds of thousands of dollars.
b) Often described as "enterprise":
n-tier, 5-50 person team, application needs to be extended and maintained over several to many years , 6-18 month development cycles, use of design patterns such as MVC, tight integration with middleware, mission critical. In my experience project budgets tend to be in the few hundred thousand dollars to the many millions of dollars.
The above is very rough and it is impossible to perfectly segment -- not all apps that may be described as "enterprise" have those characteristics of course and there are many characteristics I haven't mentioned here. But at a high level there are very large differences between applications in the first and second categories in terms of skills typically involved, budgets, timetables, technologies, and processes.
From my view at Macromedia, Flex can be used for many many things, but its sweet spot is "enterprise RIA"; Flash Professional can be used for many many things, but its sweet spot is "RIA" and Interactive Content but usually not with the "enterprise" label. To be clear, there are many many exceptions--this isn't neatly divided into two worlds.
-David
macromedia
There are some nice posts on the serverside.com discussing and comparing various solutions for enteprise rich internet apps:
http://www.theserverside.com/news/thread.tss?thread_id=24836
this is the kind of info Gartner & companies charge 1000's. Definitely worthy of checking it out.
There are some nice posts on the serverside.com discussing and comparing various solutions for enteprise rich internet apps:
http://www.theserverside.com/news/thread.tss?thread_id=24836
this is the kind of info Gartner & companies charge 1000's. Definitely worthy of checking it out.
Please have a look at my website.